Hi
Viktor Szakáts wrote:
>
> 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.
>
If you look closely the code is not activated.
I kept is like this to let me remind in future why
paint event in threaded implementation gives GPF
without enabling it.
> 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.
>
You checked wrongly. xbpgeneric.prg
/*----------------------------------------------------------------------*/
INIT PROCEDURE Qt_Start()
Qt_MutexCreate()
t_oDummy := XbpObject():new()
s_oApp := QApplication():new()
RETURN
/*----------------------------------------------------------------------*/
EXIT PROCEDURE Qt_End()
Qt_MutexDestroy()
t_oDummy := NIL
t_oAppWindow := NIL
IF hb_isObject( s_oDeskTop )
s_oDeskTop:oWidget:pPtr := 0
endif
s_oApp:quit()
#if 0
s_oApp:oWidget:pPtr := 0
#endif
RETURN
/*----------------------------------------------------------------------*/
<qupte>
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.
Yes, on my TODO list. Just finding a better way to achieve it.
May be I need to change something in .qth.
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.
This function can be removed as it is not called from anywhere.
Xbp engine cleans them transparently. It was the original concept
of Marcos but I implemented in different way. Rmoved.
Thank you for digging deep into HBQT code.
Actually I am looking for such type of observation which
was missing earlier.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/hbqt-and-MT---issues-tp26677065p26682696.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
