Am 23.03.2010 01:15, Matthias Melcher wrote: > > On 22.03.2010, at 10:15, Domingo Alvarez Duarte wrote: > >> I'm experimenting with dao http://daovm.net/ and his author did an >> amazing job creating a automated tool that can create bindings to almost >> all fltk 1.3 including deriving fltk classes, but for it to work with >> callbacks easily he needs to make "void do_callback(Fl_Widget* o,void* >> arg=0)" a virtual function. >> >> I propose to make this modification on the official FLTK sources. > > I understand why you would do this. do_callback however is the wrong function > to make virtual. It could however be quite useful to have a function, for > example called 'virtual void action()' that could be called if there is no > callback in place. That way, a user who prefers to derive a class - instead > of setting a callback - will not need to go through a static member function.
Hmm, that's problematic as well, because we have a "default callback" that enters a widget in the Fl::readqueue() that is used in some internal functions [1]. Would this action() method be called before or after entering the widget into the queue? Or would it be better to use virtual int action() that returns 1 if the action was taken, and if so, the widget wouldn't be entered into the default callback queue? BTW: this method would be called from do_callback(), wouldn't it? So what would be the difference to making do_callback() virtual? Only that it would be called only if there is no callback? Slightly confused... Okay, and here is a construction where making do_callback() virtual might really be useful: Assume, you have a derived class and use your own handle() method to catch some events, but most of the event handling is done by calling base_class::handle(). Then the base_class would eventually call do_callback(), and that's the point where the derived class would get control again to do something before or after calling the callback. This may be somewhat constructed, but it's possible and could be useful. Et ceterum censeo Carthaginem esse delendam. ;-) I.e. as I said before, this would also be a way to prevent calling clear_changed() after the callback, as it is done currently (and that I personally think to be wrong). But I don't want to insist, it's just thinking about it ... Albrecht [1] Fl::readqueue() is AFAIK something that has been implemented for Forms compatibility, but that is used for instance in fl_ask() etc. It could, however, easily be replaced by real callbacks - that's something on my todo list anyway, but there may be other usages, even in user programs. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
