> > o yes sorry, of course i meant like:
> >
> > myButton->callback(myobject.myCallback);
>
> Not sure how to explain it, but I don't think you can do that because
> polymorphism means that there could be more than one myCallback in the
> class hierarchy, and which one is called depends on which
> class is used
> to call it, which isn't known until runtime, or something like that.
Yes - that sort of thing. In essence, the compiler needs to be able to
resolve the callback function unambiguously at compile time.
The usual ways to do this are to either make the callback function be
A) a "normal" function (i.e. not a member of any class)
Or
B) A static member function of some class
The advantage of approach (B) is that, of course, the callback function
can still access any other parts of the class that may be protected or
private, whereas callback (A) could not.
If you look at code generated by fluid, you will see it uses this
approach - it declares the callback methods within each class, and also
declares static callback wrapper methods, which cast the object
Fl_Widget* passed to the static cb to the appropriate type and then use
that to call the member function callback itself, on the specifc
object...
OK, I explained that badly... Here's some code pasted out of an actual
working example...
In the header, when my "FiltWin" class is defined we have;
<stuff>
void cb_start_bt_i(Fl_Button*, void*); // object specifc, does the
actual work
static void cb_start_bt(Fl_Button*, void*); // static member, assigned
to the button
<more stuff>
And the implementation looks like;
void FiltWin::cb_start_bt_i(Fl_Button* o, void* v) {
// do stuff - this can access all the class members etc...
}
void FiltWin::cb_start_bt(Fl_Button* o, void* v) {
// this is just a static wrapper that calls the "real" member
callback code
((FiltWin*)(o->parent()))->cb_start_bt_i(o,v);
}
And then when we create the button we attach the callback to it like
this;
start_bt->callback((Fl_Callback*)cb_start_bt);
Note that this uses the static member function, which the compiler can
resolve at build time, and which will in turn wrap the object-specific
callback member function...
Well, I hope that made some sort of sense!
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
