Hi All,
1)
I'm seeing this code:
---
void MyMainWindow::paintEvent( QPaintEvent * event )
{
hb_threadMutexLock( s_mutex );
[...]
/* This is an ugly hack to control the way Qt executes its Paint Engine
* which appears to be "not reentrant". If paint message is received by two
* dialogs executing in different Harbour threads, appln GPF's.
* If current thread is forced to release CPU time then everything seems to
be
* working fine. But then this slows down the navigation considerably.
* Until this issue is resolved, it seems, we cannot implement multi-window,
multi-thread
* interface in Harbour. So sad...
*/
#if defined( QT_EXECUTE_IN_THREADS )
hb_releaseCPU();
#endif
hb_threadMutexUnlock( s_mutex );
}
---
Is this workaround a good one? To me it looks to only delay
potential problems.
2)
I also see QT_MUTEXCREATE(), but is this the best way
to initialize C level mutexes? There is also QT_MUTEXDESTROY().
None of them is called from anywhere I checked.
Probably some automatic initialization plus atexit destructors
would be needed here. It seems that the mutex should only
be initialized if MT HVM is linked. Current code doesn't make
such guarantees.
3)
QT_MYMAINWINDOW() returns non collected pointer, which means
it must be release manually, of not a leak occurs.
Same thing with QT_QEVENTFILTER() and destroy counterpart.
4)
There is RELEASE_CODEBLOCKS() which needs to be called from
user code. This hints that some things are never released
automatically. This function is also not called from .prg level
code present in SVN.
Difficult to judge what problems these will cause in a real
app, but above points look like ones which could use some
corrections.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
