Me: >> In "Adding and Extending Widgets" it says that type() "is an >> arbitrary 8-bit identifier" and "you can use it for any purpose >> you want". >> >> It seems to me that if I subclass some existing widgets, such >> as Fl_Slider, then I am not completely free to overwrite type() >> with my own arbitrary values.
Greg: > In this case, FL_WINDOW is defined as 0xf0, and the comment > from FL/Fl_Window.H says: > > .../FL/Fl_Window.H:#define FL_WINDOW 0xF0 \ > ///< window type id all subclasses have type() >= this > > So it sounds like you can do whatever you want.. but only > with the low order 4 bits if type(). > > And that's if you derive from Fl_Widget. > > type() is actually one of those things I try not to mess with > in favor of using my own type() in my derived classes because > of the above. > ... > I usually try to make my own 'flags' variable in my class, > and make methods that manipulate it, rather than overload type(). I saw the other comment in the docs about type() that it was a hold over from the Forms implementation. I was struggling to relate different uses of type() in different parts of the library to one consistent whole but it never occurred to me that I might not need to use type at all. >> Therefore, are there general guidelines on type(), or do they only >> apply on widget-by-widget basis? > I have a feeling the design is "read the source luke"; > look at how the widget you derive from is implemented, > (i.e. how it makes use of type()) and then design your work > as an extension of that implementation. My problem is that in trying to remain Fast and Light, a lot of the tool kit has avoided using specific enums or class implementations, and as a result there are a lot of uchar and int fields for types, which are initialized to 0 and all sorts of overlapping #defines are called into play in different parts of the library. I suppose that if you are creating a new hierarchy of widgets then you are free to implement RTTI within those widgets in any way you want, as long as you respect the existing use of type(). So would current developer advice be to implement local RTTI ? Or should we be looking at more modern "template" or "prototype" classes where implementation is passed in? [I'm not sure if I'm using the GoF Design Pattern nomenclature correcty here]. Cheers D. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
