Hello Viktor
Viktor Szakáts wrote:
>
> This means QT cannot be used in apps which is supposed
> to run continuously. (?)
>
> Continuously running GUI apps aren't that typical, but
> to me it's still a serious concern that and app just
> eats memory while running. This makes it f.e. unsuitable
> for any sort of embedded GUI applications (like a kiosk).
>
> 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.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25474420.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
