> I think, you are referring to the log generated by the following lines: > > HB_TRACE( HB_TR_DEBUG, ( "hbqt_gcRelease_QUiLoader Object > deleted! %i B %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) ); > > Yes, indeed the message is too optimistic, but in any case shows that the > hbqt sends a request the Qt layer to do it. > The FM statistic and valgrind output should be the basis of our > investigations. > >>> The HBQT_RELEASE_WITH_DELETE_LATER method releases the allocated memory >>> with a delay. >>> > >> So it should be out of our experiments then. I will remove from generator. > > In this way, we will restrict the possibilities of the hbqt based application > developers. > This release method is useful in a situation when the object is no more > necessary, but there are some pending events related to this object.
I can't see any guarantee that the delayed method would _ensure_ that. IMO it should be deleted to not confuse users. If there is a pending event to an object, the object should not be deleted, and this should be ensured by QT and HBQT _by default_. Currently it's not even ensured by HBQT, which is marked as TOFIX in code. (simple ptr reference is stored without reference counting). BTW, here latest HBIDE shows no more leaks, but it still crashes on exit (MINGW/WIN7). HBQT_RELEASE_WITH_DELETE should be made the default on HBQT level, and any app-level tweaking (in HBIDE, demos) deleted. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
