DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2161 Version: 1.3-current > Fl_Widget::flags_ is of type int, but there is an enum defined > that sets individual bits. Maybe it would be better to define > flags_ as unsigned int. Since it's a bit flag, I wouldn't think the sign would matter. But if someone's using + instead of | to combine flags, then it might matter a lot if that high bit is ever assigned.. > Currently there are 12 bits (1-2048) defined, but they are in > different places in the source files. Maybe it would be better > to define all bits at one place.. That certainly makes sense, though it seems 'flags' is being used the way type() is; derived classes making use of it for their own purposes. I guess in cases where bits might be used in derived widgets for other purposes, these bits should at least be marked 'reserved' or 'multipurpose' in Enumerations.H. eg: enum { INACTIVE=1, INVISIBLE=2, OUTPUT=4, // =8 reserved: Fl_Window (FL_NOBORDER) // =16 reserved: Fl_Window (FL_FORCE_POSITION) // =32 reserved: Fl_Window (FL_NON_MODAL) SHORTCUT_LABEL=64, // multipurpose: Fl_Window (FL_MODAL) CHANGED=128, // multipurpose: Fl_Menu_Window (NO_OVERLAY) // =256 reserved: Fl_Window (FL_OVERRIDE) VISIBLE_FOCUS=512, COPIED_LABEL=1024 // =2048 reserved: Fl_Group (CLIP_CHILDREN) }; ..though it's kinda messy. Either that, or as you say, all defined within the single enum. Or maybe these top level widgets should simply "bite the bullet" and add an int of their own for these purposes, instead of abusing Fl_Widget's flags value. Just my 2 cents.. Link: http://www.fltk.org/str.php?L2161 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
