DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Hi Albrecht, 1) To have global function (although as static in Fl_Menu_Item) no_close_flags(int f) is to allow user simply to change begaviour globally for isntance for all submenus by calling Fl_Menu_Item::no_close_flags(FL_SUBMENU|FL_SUBMENU_POINTER); Then it woult not be required to set any menuitem flag explicitly, so all code (for instance fluid generated) would work with new behaviour as expected 2) I an not against adding an extra FL_MENU_NOCLOSE enumeration flag, just showing that this is unnecessary as it can be done by the user. Having function no_close_flags() allows to control behaviour BOTH globaly and in per-item fasion. But adding FL_MENU_NOCLOSE to api and setting by default static int no_close_flags_ = FL_MENU_NOCLOSE; or even to static int no_close_flags_ = FL_MENU_NOCLOSE | FL_SUBMENU | FL_SUBMENU_POINTER; // breaks backward compatibility is fine with me, although the second one breaks backward compatibility 3) Your code if ( !((value_->flags & Fl_Menu_Item::no_close_flags()) && (FL_SUBMENU | FL_SUBMENU_POINTER)) ) does not make sense to me - second part && (FL_SUBMENU | FL_SUBMENU_POINTER) is a constant expression and is always true. The code change as proposed is to assure strict backward compatibility: submenus until now never called "widget" common callback (even when menu is closed) with submenu-item picked. This is to avoid calling this callback with wrong item picked - which can not be selected for instance Fl_Choice with submenu (you can not set this Fl_Choice to the state with submenu-item picked). However new code would indicate "submenu-item" as picked during callback and could even crash a program if the program relies that only ordinary items can be selected. The user still can assign a callbback directly to submenu-item if he wishes so (probably a rare case). And yes, this is a real-life case: without the change one of my applications with Fl_Choice with submenus crashed. 3) I would propose to have functions no_close_flags() NOT inlined to avoid initialization fiasco (if somebody would call this before main() or some crazy pal would call gui before main()), I would implement them in Fl_Menu.cxx as static int menu_no_close_flags_ = FL_MENU_NOCLOSE; void Fl_Meu_Item::no_close_flags(int m){return menu_no_close_flags_ = m;} int Fl_Meu_Item::no_close_flags(){return menu_no_close_flags_;} Roman Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
