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 _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
