Hello Przemek
Przemysław Czerpak wrote:
>
> Just like me looking at hbqt code ;-)
>
Yep. And this is the weired part. But it is.
And probably cannot be avoided, though I could be wrong.
> I do not understand current hbqt code. It looks that it has three
> different versions of code to manage pointers to objects and only
> one is active.
>
This is because of the inherent nature of Qt objects.
Some are direct descendants of QObject some are pure memory
objects. Some others are pure virtual and yet some others
do not allow destructions. Also some more variations I do not remember
well now.
> I'm afraid that it's hard for me to make any
> modifications in this code so I updated code for one of QT class
> (QPageSetupDialog). It's below.
>
Thanks for taking such pain. This code has provided some valuable
hints to shape up the generator once again.
> Please note that release_QPageSetupDialog and s_gcQPageSetupDialog
> are statics and only hbqt_par_QPageSetupDialog() is a public function
> not a macro which returns pointer to QPageSetupDialog. Such version
> gives very good encapsulation so you do not have to use any casting
> which may hide very serious bugs and you do not have to worry that
> pointer to different object is used by mistake. Inside GC block
> QPointer< QPageSetupDialog > is stored so it will be automatically
> cleared if object is released by other code.
>
And here is the iceberg.
If a class contains all the methods it is implementing then this
code will definitely work excellent. But what if the call is inheriting
from other which in turn again inheriting from one more, and
a method is called from parent two levels up. The same
pointer is passed along the class hirarchy which is typecasted
to parent class's pointer.
For example:
Class QWidget
method new()
method show() INLINE Qt_QWidget_show( ::pPtr )
QWidget.cpp
//
HB_FUNC( QT_QWIDGET_SHOW )
{
hbqt_par_QWidget( 1 )->show();
}
Class QMainWindow From QWidget
Method new()
Method some()
oWnd := QMainWindow():new()
oWnd:show()
The method show() will be called from class QWidget where ::pPtr
is passed along to parent class which is typecasted to hbqt_par_QWidget()
from hbqt_par_QMainWindow(). How to handle this situation ?
In previous GC scenario, your tip to have a structure with "type" field
which I changed to function pointer and the solution worked very well.
I am afraid one-to-one access of pointers is not going to
help in HBQT, though I am sure you can find a better solution.
> I also suggest to define .prg classes in a little bit different way
> which will be more efficient. In fact in Harbour and xHarbour INLINE
> messages are two times slower then normal messages because they need
> indirect EVAL() call. Anyhow it's a minor problem which can be easy
> done later when the base version will work as expected.
>
This may need only a couple of hours to implement so can be
left for the later time. Thnaks to show why this code can be slow.
Regards
Pritpal Bedi
/*** QPageSetupDialog.cpp ***/
[...]
static HB_GARBAGE_FUNC( release_QPageSetupDialog )
{
QPointer< QPageSetupDialog > * pObj = ( QPointer< QPageSetupDialog > * )
Cargo;
QPageSetupDialog * obj = * pObj;
if( obj )
{
*pObj = NULL;
delete obj;
}
}
static const HB_GC_FUNCS s_gcQPageSetupDialog =
{
release_QPageSetupDialog,
hb_gcDummyMark
};
QPageSetupDialog * hbqt_par_QPageSetupDialog( int iParam )
{
QPointer< QPageSetupDialog > * pObj = ( QPointer< QPageSetupDialog > * )
hb_parptrGC( &s_gcQPageSetupDialog, iParam
);
QPageSetupDialog * obj = * pObj;
/* TODO: RT ERROR if obj is NULL */
return obj;
}
HB_FUNC( QT_QPAGESETUPDIALOG )
{
QPointer< QPageSetupDialog > * pObj = ( QPointer< QPageSetupDialog > * )
hb_gcAllocate( sizeof( QPointer< QPageSetupDialog > ),
&s_gcQPageSetupDialog );
if( hb_pcount() >= 2 )
*pObj = new QPageSetupDialog( hbqt_par_QPrinter( 1 ),
hbqt_par_QWidget( 1 ) ) ;
else
*pObj = new QPageSetupDialog( hbqt_par_QWidget( 1 ) ) ;
hb_retptrGC( pObj );
}
/*
* virtual int exec ()
*/
HB_FUNC( QT_QPAGESETUPDIALOG_EXEC )
{
QPageSetupDialog * obj = hbqt_par_QPageSetupDialog( 1 );
if( obj )
hb_retni( obj->exec() );
}
[...]
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
--
View this message in context:
http://www.nabble.com/HBQT---Nearly-lost-how-to-implement-new-GC-tp26033190p26035057.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
