I have implemented functions to control the menu behaviour, patch submitted as 
feature-request STR #2950.

The implementation is very conservative (does not change current behaviour) not 
to break current applications but adds the programmer various possibilities how
to control when the items should close the menus.

The API consists of two additional functions, they are implemented as "static" 
of Fl_Menu_Item namespace:

class Fl_Menu_Item {
  static void no_close_flags(int f){no_close_flags_ = f;}
  static int no_close_flags(){return no_close_flags_;}
  static int no_close_flags_;

The user can globally change the behaviour - ie at the beginning of the program 
when he changes the mask of no-closing items:


User can also control the items individually like:

  #define FL_MENU_NO_CLOSE 0x200

and then OR this custom flag to the other flags for particular menu items.

On 09/04/2013 17:26, Greg Ercolano wrote:
>         ) {
> #if 0 // makes the check/radio items leave the menu up  ***
>       const Fl_Menu_Item* m = pp.current_item;
>       if (m && button && (m->flags & (FL_MENU_TOGGLE|FL_MENU_RADIO))) {
>         ((Fl_Menu_*)button)->picked(m);
>         pp.p[pp.menu_number]->redraw();
>       } else
> #endif
>       So it looks like someone's already been here with that in mind.
>       If uncommenting that works for you, I guess we should add a flag,
>       as you say, that lets the app control this. Otherwise, we're open
>       to patches..

It requires some small additional change in function Fl_Menu_::picked() (see 
submitted  #2950) because some items (like checkbox/radio) may require to invoke
callbacks even if the menus are not closed but picking requires immediate 
response (either its own callback or parent-widget's one).

Anyway I have tested my implementation (which is more conservative - does not 
change default behaviour if you do not call Fl_Menu_Item::no_close_flags(int 
f), I
do not want to break users applications) and everything seems to work as 


fltk mailing list

Reply via email to