Forum

As it is stated in the Help file "User-defined toolbars are created with the Customize dialog and cannot be reset." I’m creating numerous toolbars and menus programatically through ProfAuto interfaces. Why they appear as user-defined in Customize dialog?

And one more question. Is there some way in ProfAuto to insert menu item in a parent menu NOT side by side to a "brother" menu? The problem is that menu item loaded from MFC-resource doesn’t have associated command ID nor command name, just menu text which is not constant because of the localization.

Thank you for the information! The first question is not very important for me currently, so i’m going to the second.

The problem is how to assign a command name to menu which is not created from ProfAuto but internally from a MFC-resource. There’s no way for identifying these menus, because they have no command ID’s unlike the menu items.
I’m stuck with this.

Here is part of the IExtAutoCommand interface definition in the ProfAuto.idl file which declares the Name property defining an internal unique name of the command object:

    // Property Name
    [propget, id(57), helpstring("Gets or sets the internal unique name of the command")]
    HRESULT Name(
        [out, retval] BSTR * strInternalCommandName
        );
 
    [propput, id(57), helpstring("Gets/sets an internal unique name of the 
command which can be used to access the command object in the command collection")]
    HRESULT Name(
        [in] BSTR strInternalCommandName
        );

The IExtAutoCommand::Name property is read-write. You can rename any command. The new name of the command will be assigned successfully only if it is unique.

I think this would work to get the command id and associated commanditem of a menu entry on the top level of your menu:
UINT nCmdId = m_wndMenuBar.GetButton(nIndexOfYourMenu)->GetCmdID();
CExtCmdItem *pCmdItem = g_CmdManager->CmdGetPtr(pApp->m_pszProfileName, nCmdId);

ProfAuto is designed in a way that only user-defined toolbars can be created and this is similar to automation objects in Microsoft Office applications. You cannot also delete built-in (main) toolbars though you can modify them using ProfAuto. In other words, ProfAuto is consistent with the scripting support provided by Microsoft.

In ProfAuto a unique command name is more important than a command identifier. You can allocate commands using only command names without having to use any identifiers. The identifiers can only be used specific interaction tasks between automation-enabled languages and internal code of your application. So in most cases to assign unique command names to ProfAuto-allocated commands is the best solution. You could use menu resource identifiers to build command names but in this case, you should keep menu item identifiers persistent.