Callbacks, never ending story :)

I would actually keep recent simple method of callback. From my experience (see Fl_Signal in the basaar) once you start improving callback system,  your
appetite endlessly grows: you want object methods, you want callbacks accepting many parameters, you want to have multiple callback, chained, marshalling etc...
Anyway a sophisticated callback mechanism can be created outside the Fl_Widget class just using the user_data as pointer to your sophisticated callback ojblect
(the functor) and the callback function pointer is just a wrapper which calls the functor. You can then have a templated function (actualy mnmany of them with
different number of templated parameters) which constructs this functor and assign to the widget, for instance

     template <typename T1, typename T2, typename T3>
     void fl_callback(Fl_Widget * widget, T1 t1, T2 t1, T3 t3{
        Callback_Functor * f = new Callback_Functor(widget, t1, t2, t3); // using overloaded templated functor constructors
        widget->callback(&functor_wrapper, f);
        widget->set_flag(FL_DESTROY); // see my proposal below
     }

which would be normally used as

    fl_callback(widget, object, method, parameter1, parameter2, ...); // external callback assignment

instead of fancy version (if the widget would gave templated callback method):

    widget->callback(object, method, parameter1, parameter2, ...); // using a widget templated callback method


To me the difference between the two is just syntactic sugar not worth the bloat introduced by templating the Fl_Widget class methods.

The only thing I would add is possibility of informing the "user_data" that the widget is dying so that the functor object can be eg destroyed.
To do that, one possibility would be to use one bit among the flags to indicate that THE SAME callback function (the wrapper) should be called also when widget
dies (in its destructor) - but this time with first parameter (the widget pointer) as a NULL (the widget might be partially destructed so there is not much use
of it anyway). Your wrapper function could be then implemented like this:

    functor_wrapper(Fl_Widget * widget, void * data){
       Callback_Functor * f = (Callback_Functor *)data;
       if(w)
         (*f)(); // performing normal callback
       else
         delete f; // destroying
    }



Proposed modification to FLTK:

  void Fl_Widget::~Fl_Widget(){
    ...
    if(FL_DESTROY & flags() && callback_ && user_data_) (*callback_)(0, user_data_);   // new code
  }

  void Fl_Widget::callback(Fl_Callback * c, void * d = 0){
     if(flags() & FL_DESTROY && callback_ && user_data_)
        (*callback_)(0, user_data_); // destroying old user_data_
     callback_ = c; user_data_ = d;
     clear_flag(FL_DESTROY); // new code: with each new callback assignment the flag must be cleared to keep backward compatibility
  }

  void Fl_Widget::user_data(void * d){
      if(flags() & FL_DESTROY && callback_ && user_data_)
        (*callback_)(0, user_data_);
      user_data_ = d;
      clear_flag(FL_DESTROY);
  }

R.




On 26/11/2010 18:14, Domingo Alvarez Duarte wrote:
> The one that I found interesting start here http://fltk.org/newsgroups.php?s41+gfltk.development+v60+T0+Qcallback
> 
> And the code supplied is to add direct class method usage on callbacks in FLTK, it only add a pointer to Fl_Widget a few typedefs and inline functions and a
> modification to Fl_Widget::do_callback, it's totally transparent to existing code, all code that rely on the actual callback mechanism of FLTK work when instead
> of a static function a class method function is used.
> 
> En 26/11/2010 15:52:55, Duncan Gibson <duncan.gibson-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escribió:
> 
>>> Reading the forums I've found interesting ideas about extending
>>> the functionality of callbacks in FLTK.
>>> [...snip...]
>>
>> I'm too busy/lazy to go back through the forums to find out what
>> this relates to, and maybe just too thick to see it in the code,
>> so could you please summarize the previous forum discussions and
>> outline what this code is intended to be used for?
>>
>> D.
> 
>