Albrecht Schlosser wrote: > 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.
Thanks for you points of view, I think that the need to make possible both ways to have a callback/action through function pointer or derived class method is clear and desirable by more than one. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
