Hi Pritpal >> 1) is there some reason for having s_slots and s_events handled by the >> programmer and not hidden someway ? > > Yes, because in Harbour we are calling Qt classes by function calls > instead of class/method calls. We cannot call Qt classes directly. > Though my explanation may appear a bit tough but this is how > Harbour bindings for Qt are implemented. We are calling Qt classes > from PRG level and not from C++ level.
I understand that we are using Harbour functions to call C++ functions like HB_FUNC( QT_SLOTS_CONNECT ) that call a static function connect_signal that finally does the "real" connect, for example: if( signal == ( QString ) "clicked()" ) return object->connect( object, SIGNAL(clicked()), t_slots, SLOT( clicked()), Qt::AutoConnection ); We are passing s_slots from Harbour to connect_signal where it is HBSlots * t_slots... and this is my concern: WHY are you passing s_slots back/forth between Harbour and C++ ? Since from example number 2 slots are used (a Qt program without slots/events is almost useless..., just a basic display perhaps...) WHY don't change hbqt_slots.cpp to include a file-wide static variable s_slots, completely handled by Qt (so no Harbour GC hassle) and then remove harbour level s_slots variables ? I know it is a non compatible change (well, it may become compatible if you check number of parameters in QT_SLOTS_CONNECT) but it frees the programmer from the s_slots burden... There may be only one problem: if Qt may handle multiple slots lists... something I sincerely don't know... but, properly changing QT_SLOTS_CONNECT this may be handled too. Francesco _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
