Professional UI Solutions
Site Map   /  Register


Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS General Discussion » User-defined toolbars Collapse All
Subject Author Date
Svet Asenov Nov 30, 2006 - 11:41 AM

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.

Svet Asenov Dec 6, 2006 - 8:33 AM

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.

Technical Support Dec 7, 2006 - 1:45 PM

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.

Suhai Gyorgy Dec 7, 2006 - 5:04 AM

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);

Technical Support Dec 1, 2006 - 7:46 AM

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.