Hello All
Pritpal Bedi wrote:
>
> HB_GARBAGE_FUNC( release_QMainWindow )
> {
> void ** ph = ( void ** ) Cargo;
>
> if( ph && * ph )
> {
> delete ( ( QMainWindow * ) * ph );
>
> * ph = NULL;
> }
> }
>
> HB_FUNC( QT_QMAINWINDOW )
> {
> void ** ph = ( void ** ) hb_gcAlloc( sizeof( void * ),
> release_QMainWindow );
> QPointer< QMainWindow > pObj = NULL;
>
> pObj = new QMainWindow( hbqt_par_QWidget( 1 ), ( Qt::WindowFlags )
> hb_parni( 2 ) ) ;
>
> * ph = pObj;
> hb_retptrGC( ph );
> }
>
> The access function:
>
> #define hbqt_par_QMainWindow( n ) ( ( QMainWindow * ) hbqt_gcpointer(
> n, relese_QMainWindow ) )
>
> void * hbqt_gcpointer( int iParam, HB_GARBAGE_FUNC_PTR pFunc )
> {
> void ** ph = ( void ** ) hb_parptrGC( pFunc, iParam );
>
> /////////////////////////
> //
> // At this point <pFunc> is not NULL but <ph> is NULL
> //
> /////////////////////////
>
> return ( ph && * ph ? * ph : hb_parptr( iParam ) );
> }
>
> PRG Call:
> oWnd := QMainWindow():new()
> oWnd:anyAction() => GPFs
>
Nothing wrong. Code is correct. GPF is due to way
.prg class structure passes pointer to parent class and then
the methods of parent class cast the pointers to its native garbage pointer.
Let's analyze:
oWnd := QMainWindow():new() => Returns the correct pointer and all those
methods
which are contained in
QMainWindow() class behave
correctly.
oWnd:show() => Method "show" is the method of parent class QWidget and hence
the pointer
is passed to QWidget:show() which in .cpp is called
like:
HB_FUNC( QT_QWIDGET_SHOW )
{
hbqt_par_QWidget( 1 )->show();
}
and
hbqt_par_QWidget( n ) is defined as ( ( QWidget * ) hbqt_gcpointer( n,
release_QWidget ) )
whereas the pointer is intended to be called as
hbqt_par_QMainWindow( n ) => ( ( QMainWindow * ) hbqt_gcpointer( n,
release_QMainWindow ) )
As GC pointers need a function pointer to execute, it is simply out of
question to have
one-to-one hirarchy due to complex class structure and the way pointers are
type casted dynamically.
This only is possible as per my previous commit, so I am goint to stick with
that.
But juggling with all the above I have discoved one more fact and that is
that our current
implementation of HBQT lib is half cooked. I mean a lot more classes need to
be added
in turn to access all the methods contained in all the classes. I have all
those classes ready to be
committed but now face the problem of 8 kb command line limit to the mingw
linker.
What the group advises ?
BTW what is the overhead if one more structure to hold the GC structure as
per previous commit ?
Is not it destructed while GC function is called ? Note that repleasing the
memory is much more
important then Harbour pointer which we know how to deal with.
Waiting for feedback.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/HBQT---A-Clarification-tp25951642p25953123.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
