Hi Pritpal,
> 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.
Sorry, but it extremely difficult to evaluate code which
has plenty of #if 0's in them. Very easy to miss that
it's commented. So: If some code is not needed, it should
not be there at all, this way any such misunderstanding
can be easily avoided. Also notice that when one 'grep's
for something, such #if 0's can't be seen. It's best practice
to remove commented, unused, not needed code. We have SVN
system to remember all those bits, so it can be retrieved
in case it's ever needed in the future. Or, such bits can
be stored on local machine.
Even I could easily delete all #if 0 code, my only problem
with this approach is that such commented code reappears
pretty quickly, so this is something which should be taken
care of by developers working on that code.
>> 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
It's wrong. First of all HBQT is not only meant to be used by
HBXBP, and app code which directly uses HBQT can't be expected
to have such stubs. It's just a way to mess up ones HBQT-based app.
Such crucial initialization should be done automatically and before
.prg level code is ever executed, otherwise its another time-bomb.
F.e. even in above solution it's not guaranteed that in custom
INIT PROC, QT is already available, or that it's still available
on user EXIT PROCs.
F.e. contrib/hbwin/win_com.c has such C level automatic
initialization, plus even HBQT uses hb_vmAtExit() to clean up
stuff on exit. Probably it could be used here, too.
> <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.
That's good, thanks.
> 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.
Please remember that XBP engine is just one .prg layer on top
of HBQT. Such cleanup isn't the job of XBP, but it should be
done in a self-contained way inside HBQT to have a foolproof,
standalone component.
IOW: If someone choses not to use HBXBP, HBQT should still be
usable without low-level hacks maintained by app programmer.
This is also a basic requirement to freely mix HBQT and HBXBP
APIs together in one app, like hbide.
> Thank you for digging deep into HBQT code.
> Actually I am looking for such type of observation which
> was missing earlier.
No problem, and sorry to sound harsh sometimes, it's not
meant as personal disrespect or an attack against HBQT, but
I'd like to get these messages straight, especially since
I've told some of them already, and similar problems keep
reappearing from time to time.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
