Hi Pritpal,
Is this a property of QT itself, or the property of Harbour wrappers?It is a property of Qt itself. I have made extensive experiments as far as Harbour's parameter passing is concerned and have reached to the conclusion that it is harmless. Experiments with Qt's object destruction has given me weired results. For example: oRect := QRect():new( 20,20,30,400 ) ? oRect:left() => 20 ? oRect:top() => 20 ? oRect:right() => 30 ? oRect:bottom() => 400 Qt_QRect_destroy( oRect ) ? oRect:left() => 4534342 ( a long figure ) ? oRect:top() => 8967354 ( another long figure ) ? oRect:right() => 30 ? oRect:bottom() => 400 .cpp HB_FUNC( QT_QRECT_DESTROY ) { delete hbqt_par_QRect( 1 ); // OR/AND hbqt_par_QRect( 1 )->~QRect(); } So even after destroy, oRect is an active pointer and only firts two slots are pointing to garbase. In theory after destroying it it should raise som error or appln must hang, but results are contrary. Though I have not given up, YET, on this issue, but at the face value ( till now ) it appears we cannot use Harbour-Qt for production level applications. NOTE: struggle is still on to overcome it.
Thanks for the explanation and details. Could it be that QT uses some sort of lazy freeing of the objects (f.e. to keep user apps not crash when doing object access after freeing, and/or to maintain compatibility with earlier QT lib releases, or there could be others reasons also), so that actual freeing happens only later in a "gc-like" phase? If so, maybe there is a way to control that directly or indirectly. Looks like an issue which would make QT unsuitable for a lot of uses (embedded systems), so I'd guess they have solved this issue somehow. Some easy googling gave this result: http://lists.trolltech.com/pipermail/qt-interest/2008-December/000458.html This might help understanding its internals. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
