Bisz István wrote:
>
>> BTW the only one thing which should be introduced yet is an option to
>> mark GC pointer items as attached to other QT structures so they should
>> not be released automatically with the HVM item because they will be
>> released with parent object.
>
> Yes, indeed, this is the solution for the so hunted GPF-s in HBQT.
>
> In the attachment is the hbqt patch for the hbide crashes in different
> circumstances.
>
> The problem is generated by the following sequences in searchreplace.uic:
>
> horizontalSpacer = new QSpacerItem(40, 20, QSizePolicy::Expanding,
> QSizePolicy::Minimum);
> horizontalLayout->addItem(horizontalSpacer);
> and
>
> horizontalSpacer_2 = new QSpacerItem(40, 20,
> QSizePolicy::Expanding, QSizePolicy::Minimum);
> horizontalLayout_2->addItem(horizontalSpacer_2);
>
> The QSpacerItem is not in inherited from QObject and in this way Qt has no
> information about the deletion of the object executed by hbqt. After
> deletion of the QSpacerItem by hbqt the subsequent delete of the
> horizontalLayout or horizontalLayout_2 generates in Qt engine the deletion
> of the child object, in our case the already deleted QSpacerItem...crash.
>
> The attachment contains:
> a. QLayout.cpp the generated cpp file.
> b. QLayout.qth with the modified QT_QLAYOUT_ADDITEM:
>
> <CODE>
> ...
>
> HB_FUNC( QT_QLAYOUT_ADDITEM )
> {
> QGC_POINTER * p;
> QGC_POINTER * q;
>
> HB_TRACE( HB_TR_DEBUG, ( "Entering function QT_QLAYOUT_ADDITEM()" ) );
>
> q = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
> p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 2 );
>
> if( p && p->ph && q && q->ph )
> {
> HB_TRACE( HB_TR_DEBUG, ( "QT_QLAYOUT_ADDITEM() Qt oject: %p is
> attached to: %p", p->ph, q->ph ) );
> p->bNew = HB_FALSE;
> }
>
> hbqt_par_QLayout( 1 )->addItem( hbqt_par_QLayoutItem( 2 ) );
> }
> ...
> </CODE>
>
> c. THbQtUI.prg with the corrected sequence:
> ...
> HB_TRACE( HB_TR_ALWAYS, 101 )
> ::oWidget:close()
> HB_TRACE( HB_TR_ALWAYS, 102 )
> ::oWidget := NIL
> HB_TRACE( HB_TR_ALWAYS, 103 )
> hbide_justACall( i )
> RETURN NIL
> ...
>
Welcome back, we really missed you.
Though above solution is exactly what effectively handles the
situation, and you have well described it, it is not the only part
where it may fail. Such scenarios can be many, especially when
we are handelling .uic files at the prg level. Also it requires a
manual update of such methods on .qth levels, which in
my opinion is not the right solution.
Przemek's second option is to introduce GC items dependant on
some other is the right direction to go.
-----
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4907776.html
Sent from the harbour-devel mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
