Will be good if possible if sameboy [like Pritpal] found a way in hbide,hbqt.hbxbp that when a compoment not work the application will continue also without this part, this be usefull for platform like os2,ubuntu,mobile platform with partial support SET INGNORE ERROR Better partial that nothing
2010/3/20 Pritpal Bedi <bediprit...@hotmail.com>: > > > David Arturo Macias Corona wrote: >> >> Tests with Harbour fresh checkout: >> * $Id: ChangeLog 14189 2010-03-19 13:11:59Z vszakats $ >> 2010-03-19 14:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> >> os2qt development has moved to Qt462 >> Current tests with os2qt462 r701 >> >> so we have a newer Harbour and newer os2Qt462 >> > > Thanks for your constant efforts, someday we will reach a solution, for > sure. > > > >> With our 4 specific error cases >> - one has been fixed (a) >> - one changed behaviour (c) >> - two remain with same behaviour (b, d) >> >> >> a) demoqt.prg >> Case: QT_QWIDGET_RESIZE(0) >> PMMERGE 3:0007f6f8 >> Fixed >> For first time in history I see demoqt.exe running on OS/2 >> > > > All the good. > > > > >> b) demoqt.prg, MsgInfo( "Testing" ) added >> Case: Object destruction >> LIBC063 0:000669ca >> Remain >> Question: Is this a common problem in hbqt in rest of platforms, or >> exist only in OS/2 ? >> > > > This is the behavior of GC and Qt's destruction mechanism, see below. > > > > >> c) hbide project >> Case: hbide crash at startup >> LIBC063 0:000669ca >> Changed behaviour >> >> In current behaviour, show logo and never build window, then crash >> > > > Probably fixed in r14198, please test. > It is again a "destruction of object" issue. > > > >> d) demoxbp.prg >> Case: QPIXMAP:SCALED(0) >> LIBC063 0:000669ca >> Remain >> >> Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg >> > > > This is bug in OS Qt in QPixmap() class. > Tell Dmitry specifically pointing to this issue only. > > > > >> Regarding the object destruction in Qt. I don't know if this is relevant >> or not, >> but Qt uses a lot of global and local static objects (in terms of C++) >> that get >> automatically constructed at program startup and destroyed at >> termination. In >> C++, the order in which these objects are constructed and destructed, is >> not >> guaranteed. I found one bug related to this issue in Qt itself (see r599 >> in the >> SVN) but there may be more. >> > > > The above reply portrays the snapshot of our GC way of destruction > and how Qt handles them, all timing problem. This is one factor I always > struggle about. If we do away with GC pointers, everything goes OK > but then application keeps on eating memory unless we reuse > the objects, that was the case with first few months of development. > > I am writing an artical on Harbour-Qt implementation focusing > on object creation and destruction mechanism. Once that is in place, > we can request netlabs to look into it deeply and suggest us > what should be our strategy. > > Thank you for constant efforts. > > > ----- > enjoy hbIDEing... > Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/OS-2-Harbour-14189-hbqt-tp4768265p4768762.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 > -- Massimo Belgrano Iscritto all'albo dei CTU presso il Tribunale di Novara per materia Informatica Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962) Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
