Using arrays for menu trees is one of those old relics from original FLTK. We have been trying to make it bearable by adding some convenience methods. 

So when you declare a menu array, it is located in read-only memory and therefor `const`. Once you link it to a widget derived form `Fl_Menu_` and use `add()`, Fl_Menu_ will clone the original menu into red-write memory and values within the menu are no longer `const`, so you can safely cast away const. Note however that adding more menu items  may cause Fl_Menu_ to reallocate the menu array and create a new clone, making previously found pointers invalid.

Fl_Menu_::add() returns the index of the newly added menu item. So `int ix = myMenuBar->add("Edit"); Fl_Menu_Item *mi = myMenuBar->menu()+ix;` will return a pointer to the menu item that you just added. 

There are other functions to find the index of a menu item: Fl_Menu_::find_index() , or find the menu item itself: Fl_Menu::find_item(), find_item_with_argument(), find_item_with_userdata(). Yes, it can be cumbersome, and yes, actively changing the menu array may cause relocation of the array. FLTK 1.5 will add menus that use the same parent/child API that FLTK windows and widget use.

I like to use a trick to avoid re-allocating menu item arrays: I reserve an array large enough to hold everything I may ever add, but I keep the spare items invisible using the `FL_MENU_INVISIBLE` flag (or call hide() on the menu item).

Hope this helps a little.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/5a40c19a-f538-4cbe-bea1-80911ca63d33n%40googlegroups.com.