Forum

Hi,
When I add the following block of code to the ProfStudio sample

    if( !CExtCustomizeSite::EnableCustomization(
            this,
            __ECSF_DEFAULT
            )
        )
    {
        ASSERT( FALSE );
        return -1;
    }
    CExtCustomizeSite::CategoryUpdate( IDR_MAINFRAME );
    CExtCustomizeSite::CategoryMakeAllCmdsUnique();
    CExtCustomizeSite::CategoryAppendAllCommands();
    CExtCustomizeSite::CategoryAppendNewMenu();

the m_wndComboWebLoaction combo in the m_wndToolBarWeb toolbar doesnt show up.

Is there something different that needs to be done in this case for the combo to showup correctly?
Thanks

I have no problems with it! I noticed the ASSERTs when adding customization support to my existing application as part of moving to Prof UIS. Its just that the ASSERTs are pretty annoying in the debug build.

Yes I am using customizable toolbars and menus. As I mentioned in my previous post, I did some minor modifications to the StyleEditor sample and couple reproduce the problem. Add the ID_SEPARATOR to the resource file for the ID_VIEW_STANDARD_BAR toolbar and run the application after cleaning up the Prof UIS registry settings. Then run the app twice and you will see the problem.

In non-customizable toolbars and menus, there can be a separator as the first menu item or toolbar button. The separator is implemented as a standalone UI item with command identifier equal to zero.

Customizable toolbars and menus are based on command tree nodes and there are no nodes which correspond to a separator UI item. But there is a "group start" property in each node, which means a separator should be displayed before the toolbar button/menu item. You can see the appropriate command in the context menu displayed over toolbar buttons and menu items in the customize mode. The "group start" option is disabled for the first button in each toolbar and for first item in each menu. This is defined by the design of MS Office customizable toolbars and menus. It is a limitation for customizable toolbars and menus in Prof-UIS and we do not see any problems with this.

Could you please explain us why you need a separator as the first item? What is the reason for having a separator between toolbar gripper and first button?

There seems to be some issue in loading the state when the separator is the first item in a toolbar. Add a separator to the ID_VIEW_STANDARD_BAR toolbar of the StyleEditor Sample. Prof UIS throws an ASSERT.

Please let us know if you are using customizable toolbars and menus? Could you reproduce the problem using any of our sample applications and send it to us?

You should not use the combo box common control nor edit common control in customizable toolbars and menus. Please use built-in Prof-UIS combo/edit fields. The user can drag-and-drop any combo/edit fields between customizable toolbars and menus. As result, several copies of one field may appear. The CExtCustomizeSite class provides automatic data synchronization between several copies of one field and this is the main reason not to use combo/edit common controls in customizable toolbars and menus. Please take a closer look at the StyleEditor sample application. It is very simple application which demonstrates how to work with built-in combo fields in customizable toolbars and menus. A set of CExtCustomizeSite class virtual methods are overridden in the CMainFrame class for implementing editor and popup list box event handling of the built in combo fields.

StyleEditor sample uses customization and has combo boxes in toolbar. I found these commands that I think you are missing:

CExtCmdItem * pCmdItem;
	pCmdItem = g_CmdManager->CmdGetPtr( pApp->m_pszProfileName, ID_SE_STYLE_LIST );
	pCmdItem->StateSetCombo();
	pCmdItem->StateSetResizable();
	pCmdItem->m_nTextFieldWidth = pCmdItem->m_nDropDownWidth = 120;
	//pCmdItem->StateSetTextFieldNotEditable();