>>> It is perfectly normal to pass a QPushButton to a function that >>> expects a QObject !!!!!!!!!! since QObject is a super-class ! >>> >>> Since we don't store the object hierarchy Pritpal just checks that >>> ClassName() starts with a Q or HB .... and keeps the finger crossed... >> >> That's even worse than handling everything as the base class. > > It's not a different situation from c++... > >> First I think we need to make sure we can identify the >> class of every GC allocated objects. > > If you do this, you need to implement and mantain a class hierarchy in > the code, checking ancestors for every access. And since every Gui > object . Probably as first step we may differentiate between > "base-classes": this will avoid some class of problems....
Yes, but AFAICS this hierarchy is already replicated in .prg level wrapper classes, so it's not new information, only the storage format would be new. Of course it would be nice to store this in an elegant way and without redundancy. > Also, we must keep in mind how some methods are redefined.... > Example from QRadioButton.... > 14 protected functions inherited from QAbstractButton > 37 protected functions inherited from QWidget > 7 protected functions inherited from QObject > 1 protected function inherited from QPaintDevice > > If I call qRB:height() actually is called a QWidget:height() that is: > RETURN Qt_QWidget_height( ::pPtr ) that is: hb_retni( > hbqt_par_QWidget( 1 )->height() ); > and hbqt_par_QWidget( 1 ) becomes, in a "strict" type checking as > per my (unpublished) proposal: hbqt_par_QWidget( 1, > &pointer_to_qwidget_destructor )... since ::pPtr was created by > QRadioButton, hbqt_par_QWidget will return NULL.... If we have a matching .prg level hierarchy this shouldn't be a problem, but I'm letting others to contribute, I'm not enough of an OOP/GC expert. >> For this we also need to maintain the layout >> of the QT class hierarchy. This raises other issues, like >> how to keep this in sync with QT version. This information >> BTW is already maintained in HBQT on the .prg level. > > Yes, it is, not completely but it is. (BTW: muliptle inheritance is > possible in harbour ?) I don't know. Other question: Does QT code use multiple inheritance? >> Another random thought: Maybe it would be worth to >> investigate if it would be useful to merge current >> separate .prg level HBQT class wrappers with low-level >> method implementations on the .cpp level. > > low-level method implementations can be merged, and it would be good > to make them static (calling them directly is a way to problems). But Yes. > some hbqt_gcAllocate_Q* functions are called from other objects and so > they can't be hidden... That shouldn't be a problem. HBQT doesn't publish a C level interface anyway. >> In Harbour it's possible to create classes purely in .c/.cpp >> code, so this may give performance and may help maintaining >> the whole thing. (see src/rtl/errapi.c) > > I saw a library where c code was included in a prg file by a #pragma... We don't allow that in Harbour code, moreover it doesn't solve anything compared to current solution, it just meshes .c and .prg into physical file. I meant pure C class declaration / definition. >> BTW, if we could properly identify object types, current >> hack of method overloading on the wrapper level could also be >> change for a better solution. > > There are easy and not easy solutions, at both c++ and prg code > level.... In some objects there is already a form of constructor > overriding, as in QRadioButton, > in other similar cases there is no overriding (QPushButton has 3 > constructor).... > > if( HB_ISCHAR( 1 ) ) > pObj = ( QRadioButton* ) new QRadioButton( hbqt_par_QString( 1 > ), hbqt_par_QWidget( 2 ) ) ; > else > pObj = ( QRadioButton* ) new QRadioButton( hbqt_par_QWidget( 1 ) ) ; So it seems current solution is not consistent, or there is a rule which controls this. Pritpal could tell it. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
