Forum

I’m using version 2.82 freeware in my application.  I’ve found that when I begin using menu items, which changes the most used items for highlighting purposes, that the application fails to initialize until the block0x00000000 registry key gets deleted from beneath CommandManager.

I used the prof-uis app wizard to generate the application and changed no code when it comes to the initialization of the application.  Is this a known problem and is there a fix for it?

I’d like to revisit this issue.

I’m using menus on multiple windows (some menus are on dialog windows).  Currently, the way my app is set up is I am initializing the command manager in MainFrm.cpp (the main application window) with only menus and toolbars that reside on that window in CMainFrame::OnCreate.  Other toolbars and menus are added and removed to the command manager when their respective windows are created and destroyed.

The application is crashing because it is failing to load the command manager registry keys.  Are you telling me that I need to initialize the command manager with the menus and toolbars that are associated with other windows that have not yet been created in CMainFrame::OnCreate as well?

If this is the case, do I use the same profile name for all toolbars and menus?  If I do use the same profile name, how would I create these menus and toolbars on the dialog windows when they are needed?  And also, how would I release the menus and toolbars when the dialogs are destroyed?  Currently, the menus are created and added to the command manager in (CDialog)::OnInitDialog and they are removed from the command manager and destroyed in (CDialog)::PostNcDestroy.

This obviously must not be correct as the application crashes intermittently until the registry keys are removed.

Thanks for the assistance in advance.

First of all, the command manager state serialization does saving/restoring of the command usage statistics used by expandable popup menus. If your application does not use expandable popup menus, then you don’t need the command manager state serialization at all.

The state serialization code of the command manager requires the same set of commands be registered when the g_CmdManager->SerializeState( . . . ) code is invoked for state loading and state saving. This means you should preliminary register all the commands used in your application including toolbar, menu bar and context menu commands via updating the command manager from all the menu and toolbar resources.

If you have dynamically loaded parts with their own set of commands which even may have command identifiers intersected with main frame’s command identifiers, then you have reason to make these dynamic plug in modules using their own command manager profiles.

So it’s conceivable that the MRU functionality in my software could possibly be the culprit of the failed application loading because I’m not setting the MRU commands as basic when they are added to the file menu?

If this is the case, I wouldn’t know how to set those commands as basic.  I’m using MFC’s builtin support for MRU’s to handle those menu items.

Other than the MRU items, I’m not changing any other control bar, or menu in the application.  And all windows that have toolbars/menubars are using ProfileAddWnd, and ProfileRemoveWnd when the window is created and destroyed.  And the command manager is updated at startup via the code that your AppWizard generates.

All the MFC’s built-in MRU commands (ID_FILE_MRU_***) do affect the problem with command manager state serialization in your project. Prof-UIS menus well support standard MRU commands and you can see this in the DRAWCLI sample application. Please ensure you have updated the command manager from all the toolbars and menus during startup. You should also update it from all the menu resources used in context menus.

Is there a workaround for this issue?

As of right now, the application will not start until the block0x00000000 registry key is deleted.  Once you delete that, it will run successfully once.  After the application is closed, it will fail to start again until that registry key is deleted again.

At this point the command manager not loading is making the application unusable.  I have turned off the expandable menus since I only care about getting the app to run, not about keeping track of rarely used commands.

The problem will be gone if you allocate all the commands in the command manager during application startup. This means you should update the command manager from all the toolbar and menu resources at startup. If you need to allocate some commands dynamically at run time, then you should mark these commands as basic. In this case, the number of rarely-used commands in your application will be persistent and command manager will load its state without any problems.

The command manager requires that you provide the same set commands when the application is loaded and exits. We can make it not-crashing and accepting variable command sets, but the command usage statistic information will not be correct if the number of non-basic (rarely used commands) was changed.