Callback for Enhanced Menus

I'd like to be able to update the menu of a window and change the callback routine that will now process the newly set menu.

As the user tunnels in, the menus for the window should change to reflect the current operations, and the callback needed to process this new menu would have to be set.

I don't see any way to do this without closing the current window and redrawing a new window with a new enhanced menu callback specified.

But I think I'm missing something in the documentation that would show me the way.

Thanks in advance.

Can you provide a program that illustrates where the menu items will differ?

It may be possible to use %nw but I suspect you may need to use Windows API functions directly.

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 have made progress (small example), and discovered a few things.

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.

Bill,

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.

Eddie

Eddie, great suggestions. I'll look in to it.

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.

Thanks, Paul!