Hello Przemek
Thanks for the detailed analysis.
My question was targetting another issue, though.
Perhaps I could not explain what I was asking about.
I have redesigned and reimplemented destructors
in another way and mostly everything is working fine.
Your analysis
> I do not think so. Any code like:
> return ( ph && * ph ? * ph : hb_parptr( iParam ) );
> is potential source of GPF. If ph is NULL then user passed wrong
> parameter.
> If *ph is NULL then parameter was freed by QT. In such context using
> hb_parptr( iParam )
> breaks functionality given by using QPointer class because the fact that
> references were cleared is ignored and code code access wrong memory
> area. It can be source of any other unexpected behavior so it's hard to
> analyze your problems because it's possible that they are caused by above
> peace of code.
>
Has valid concerns but this is how HBQT is implemented from the
inception. I will explain why I call like
return ( ph && * ph ? * ph : hb_parptr( iParam ) );
in a couple of days after committing next which resolves
a lot of concerns. Then probably you would guide me in a right
direction concerning this issue.
> HB_FUNC( QT_QWIDGET_SHOW )
> {
> QWidget * qw = hbqt_par_QWidget( 1 );
> if( qw )
> {
> qw->show();
> }
> }
>
This part is easy and has to be taken care by the generator.
So this can be implemented in no-time. But before this I would
like to carry other experiments.
Please keep on guiding in this direction.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/HBQT---A-Clarification-tp25951642p25981722.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
