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 Roman, 1) I didn't write that I didn't want that global flag, and I understood what you wanted to achieve with it. That's all okay so far. 2) It was not the point that adding a new flag is "unnecessary as it can be done by the user". My point is: we should *avoid* to make the user set any flags in the menu items except those that are defined in the library. One argument is to be free to define other bits for new use cases within the library w/o risking damage if a user defined exactly this bit for his purposes (as it would be possible with your primary proposal). Therefore I am for adding this extra bit to the enumeration within the library. Only that was the reason to do it like Greg proposed, everything else just like your proposal would be okay with me. 3) Yes, you're right, my code was bad - I was in a hurry. But I still believe that the callback issue is another issue unrelated to the no_close flag, so this shouldn't be mixed. However, I don't have the time to think further about it now, so I'll post later regarding this. 4) to your new code proposals: okay with one exception: if we use the FL_MENU_NOCLOSE flag, then it would be handy to change this one: void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ = m|FL_MENU_NOCLOSE;} so that FL_MENU_NOCLOSE will always be set in the flags for testing. Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
