> Yes. But Pritpal says that we don't have such cases and the problem is
> only in destructor... Infact I proposed that bNew status bits to
So such change can do no harm and should be done
to prove this statement of Pritpal and avoid any
future misunderstandings in this regard.
But, I doubt current situation is clean. To me this
little code shows a clear GPF situation, when no, or
wrong 1st parameter is passed to this function:
HB_FUNC( QT_QPUSHBUTTON_SETAUTODEFAULT )
{
hbqt_par_QPushButton( 1 )->setAutoDefault( hb_parl( 2 ) );
}
NULL check seems clearly required, otherwise '->'
may just fail.
> So I believe that each QGC_POINTER_Q* that has no pq member can become
> a QGC_POINTER, while for the others that have the pq member a C++
> expert should tell if QPointer< * > pq; is supported.
>
> I found also a case where QGC_POINTER_QHttpResponseHeader is defined,
> but a standard QGC_pointer is used....
Yes. Plus check TOFIX notes in HBQT code, and it's
worth to carefully read Przemek's recent quick summary
of HBQT problems, there are some important issues
raised there which may help finding the right direction.
(f.e. confusing/mixing raw pointers with GC collected
ones, which is another clear GPF situation).
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
