Hi Istvan, > Yes, this is the final structure, as the handling mode should be dynamic, > please consult the Qt documents. Is in specified cases is recommended to use > the "delete later" feature what is the default for the actual interface > implementation. After consulting the actual Qt documentation and discussions > on the adequate sites please live it at is, is a conscious decision from my > side, to offer the flexibility to adopt the existing and future decisions of > the Qt developers. > >> IMO we should only leave one, the one which works >> the most efficiently and without leaks. > >> Is it time to make the decision yet? > > This is not black or white issue, it's not a race situation here, studying > the Qt documentations, we need a dynamic approach here. In some situation > the best solution can be different, so please close this issue, I > intentionally put that things in the code, maybe we are less informed, but > studying the Qt documents...
Thank you for the explanation. Probably some short docs would be nice to see the difference between these methods though, as without it, it's very difficult for users to make use of this feature or decide whether it's needed at all for real Harbour QT apps/users. Until then to me it looks like passing a sophisticated decision onto users. > But as a final conclusion, WE ARE NOT FACING WITH MEMO LEAK ISSUES regarding > the Qt interface automatically generated. The problem is with our > measurement instruments! We will need help here to demonstrate it, if is the > case. The actual Windows implementation is not adequate to decide the memory > "consumption" as the windows internal are so complicated. I tried to tune > somehow the Pritpals algorithms but without success after studying some > sites, sorry. For the most part this is true, however (and I wonder if anyone reads my mails on this list :( ): - There are some inherited/HBQT-only classes which are not equipped with automatic GC collection. - Some resources still need manual deallocation (like mutex, slots and events, per app and/or per thread) Making a little mistake on the .prg-level can easily cause a leak, and there are signs that such leaks are present even in current .prg code (posted about it already: MyMainWindow in HBXBP). > So my general feeling is that the 'memory' problem is solved by the > automatic generated code! For these things demonstration we have to work > hardly. IMO above issues should be inspected, and a generic solution developed to cover them and avoid repeating them in the future. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
