> Note: I rearranged your questions to match my replies better ;-) > > On 06.06.2011 23:17, anon wrote: > > > My question is: is it safe to do all event handling inside > > a MySubclass::handle() and and forget callbacks altogether ? > > Yes. > > > In any case, there is (AFAIK) a much more limited selection of > > events that some widgets can be notified about with callbacks, > > in contrast to those available to the virtual handle() method. > > Yes... > > > Is the point of callbacks to provide a "simpler" procedural way > > for event handling ? > > Yes. ;-) > > You can think of three levels of event handling or whatever you > call it to get data from the user (interface) to your application's > code. > > 1) no direct event handling, but you get all your data by calling > the widget's value() method. Of course you will need to handle at > least one event (usually a button callback) to call the value() > method(s) of other widget(s). > > 2) callbacks are used as a simple interface without the need of > deriving your own class. As you said, this is designed so that > you can access only a little amount of events (usually a button > click or changing an input widget). You can control it only a > little by using when() to decide when you want a callback to > happen (e.g. for each key press or only when the input widget > is left after it has been changed). > > 3) if you need more control, then you must derive your own class > and use the handle() method to handle the events. Here you can > do much more (as you said), e.g. change the widget's look when > the mouse enters the widget (highlighting). If you like, you can > also call the callback for your user code, thus you can define > your own callback logic. > > > Since my callbacks are outside of my classes (I have seen avideo where the > > author encapsulated them in the class, but I couldn't > compile that way, but let's forget about this), > > The key to this is to use a *static* class method, otherwise > you will get compilation errors, since the callback is store > as a function pointer. > > > which forces my to declare variables globally (or in a namespace) and > > generally clutter up the .cpp source, I though to myself, wouldn't it be > > nice if callbacks were registered as classes with a dictated method name > > for the callback, so that this way one could encapsulate variable/pointer > > declarations inside class prototypes and clean up the .cpp source ? > > To achieve this (if I understood you correctly), FLTK would > have to define one static method for each class and one more > normal class method to call as the callback, and this would > have to be done for all classes, even if you don't need it > in your particular application. FLTK is designed to be small, > and this would add mostly unneeded overhead, IMHO (although > this wouldn't be very much). You would still have to override > this fixed method by your own callback if you want different > callback functions to be called for different widgets of the > same class. > > Albrecht
Excellent, using handle() exclusively now. Thank you for the informative Albrecht. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
