%nw allows you to change the properties of an existing window. In particular you can use %nw to define or redefine %mn - Menu and %pm - Popup Menu menus on the fly. This includes %em - Enhanced Menu enhanced menus but not old enhanced menus (%`mn and %`pm).

Paul, I cannot post the program; it is far too long. But I can describe what I was intending to do.

The initial window allows one of a set of processes to be selected to be run. One of processes selected has within it a new set of lower level processes that can be further selected. It would be through this same initial window, and subsequently when returning to the initial window, that the menus and associated call back would be altered.

This would allow the program to be used without changing the structure of the modules that can be selected. If the menu callback cannot be dynamically changed, then the entire structure of the underlying program would require an overhaul. This is something I'd like to avoid.

I have a method that I am considering, but it is not as clean and transparent as it would be if the menu callback can be changed.

My other alternative is to have the initial window close and subsequent windows created for the lower level processing selections. I prefer that even less, although it would preserve the program structure better.

I can leave the main menu defined as it is (%mn) in the initial window. If I need to change the menu, I can use the handle (from %hw) and create a new menu for the window using a combination of %nw and the %mn commands. I am not using enhanced menus in my small example.

I was successful changing the menu within the handler for the menu click. This is something I need to be able to do, and it works fine.

This ability will cause minimal recode efforts. The biggest recode will be to separate the winio@ calls for menu creation into a subroutine/function so I can set or restore it at will using the %nw to precede it.

The suggestion by John Silver were most helpful in pointing me to the best place to start.

You should beware of reinventing the wheel, as users don't like too great a departure from the Windows norms they are used to. On the other hand, your description does sound a lot like a cut-down version of the MS Office apps 'ribbon'.

What about running the different windows from a 'hidden' master window, and just display the current child window, complete with its own menus and toolbars? You can prevent any window showing up in the taskbar by giving it the [toolwindow] attribute. When you change window visibility you can position and resize the new one to match the window you are changing from. Don't hide the old one until the new one has loaded - which is pretty quick.

Most of this "experimentation" is to determine, just in case, what my options are. For example, if I can disable a menu selection dynamically (some of the processes are mutually exclusive), then it goes a long way to keeping the software architecture the same while letting the user enjoy a more Windows like experience.

Whatever I learn, I'm happy learning it, even if it is not what I wanted as a result!

If %nw can be made to work in this context then it may be the best option.

Another possibility is to add a "dynamic" feature to your menus. This is described in the documentation for %mn but as such is not helpful in this context. However, it does introduce the idea of getting a menu handle when constructing %mn and then using it in calls to add_menu_item@ and remove_menu_item@.

Of more interest is the fact that the new ClearWin+ "design" mode provides an alternative mechanism for creating menus which can be used independently of a "design" process. In this alternative, menu items are first defined with the usual attributes together with an identifying name for the item. "Sub-menus", popup menus and main menus are then constructed from lists of named menu items. This approach includes a mechanism for creating "dynamic" elements that provide menu handles that are used in calls to add_menu_item@ and remove_menu_item@. Further information is available in cwplus.enh item 395, starting at the description of %qi.