You can see it in void CEmbeddedFrame::Serialize(CArchive& ar)

of Samples\Common\CommandBarsDesigner\EmbeddedFrame.cpp

Yes, I looked at that, but in order to understand that requires a lot of knowledge about the internals of the toolkit.  Like, where in a normal application does the variable m_pControls get set? That appears to be a critical element of the Serialize function.  Does this imply that the embeddedframe class must be incorporated into a user application in order to create a .xcb file for the controls created in that application?

I can add the following code to my application, which does create a valid xcb file, which I can read back into my application.  However, the CommandBarsDesigner sample application cannot load the file (it aborts looking for command bar id 0XFFEEFF.  Also, I have an Animation control bar that does get created when I load the xcb file into the application, however the animation itself is never loaded.  I checked the function:

 int CMainFrame::OnCreateControl(LPCREATECONTROLSTRUCT lpCreateControl)

which does get called, but the nID for the animation is not passed to this function.

So I guess the question is, what is the crazy stuff related to command bar id 0x(FFEEFF) when it comes to the CommandBarsDesigner application?  And why, when loading from a xcb file, the animation nID is not getting passed to the OnCreateControl function?

The following is my code to create the xcb file.

 void CMainFrame::DoSerializeCommandBars(CArchive& ar)
 {
 CXTPCommandBars* pCommandBars = GetCommandBars();
 CXTPImageManager* pImageManager = pCommandBars->GetImageManager();
 for(int i = 0; i < pCommandBars->GetCount(); i++)
      {
      CXTPToolBar* pTBar = pCommandBars->GetAt(i);
      pTBar->GetControls()->ClearOriginalControls();
      }
 // Save Docking Position and Controls
 pCommandBars->SerializeBarState(ar,TRUE);
 // Save Icons
 pImageManager->Serialize(ar);
 // Save Accelerators:
 XTPShortcutManager()->SerializeShortcuts(this,ar);
 // Save Options
 if(m_nTheme == ID_THEME_NATIVEWINXP)
      m_Theme = (XTPPaintTheme)xtpThemeNativeWinXP;
 if(m_nTheme == ID_THEME_OFFICE2003)
      m_Theme = (XTPPaintTheme)xtThemeOffice2003;
 ar.Write(&m_Theme,sizeof(XTPPaintTheme));
 pCommandBars->GetCommandBarsOptions()->Serialize (ar);
 // Save m_bCustomizable
 m_bCustomizable = FALSE;
 ar << m_bCustomizable;
 // Save Dummy Rectangle
 CRect rc(10,10,300,300);
 ar.Write(rc,sizeof(CRect));
 }

Ah, I see the problem now.  Although my program can correctly load the .xcb it created, the CommandBarDesigner cannot since my application uses classes such as CControlTools.  This causes the CommandBarDesigner to abend in the LoadCommandBarList() function.

So I guess CommandBarDesigner will not work with any menu and or toolbar that uses CControlTools or anything esle other than a plain old menu or toolbar item.

Good concept, but rather useless.

It would appear the the problem referenced above is not due to any problem in the CommandBarDesigner example application.  When I trace the calls made, functions with the toolkitpro api is expecting the custom controls to be serialized within the .xcb file.  However I see no facility to be able to accomplich this in the creation of the .xcb file itself.  The end result is the toolkitpro api attempts to locatate the serialized controls within the .xcb file, thus messing up the pointers used to read the file, and results in an message "unexpected format".

A second problem happens when loading an .xcb file into an application, within the mainfrm OnCreate function, it appears that when the following functions are called:

 CXTPPropExchangeSection secShortcuts(pPX->GetSection(_T("Shortcuts")));
 XTPShortcutManager()->DoPropExchange(&secShortc uts,this);
 

will cause MFC to ASSERT in LoadAccelerators.  Note that since the mainfrm function LoadFrame calls:

 if(!CFrameWnd::LoadFrame(nIDResource,dwDefaultStyle,pP arentWnd,pContext))

then the the accelerator table pointer is not NULL, thus the ASSERT.

The .xcb file is loaded correctly, and all the command bars are created correctly, you just get the ASSERT.  I suspect the accelerator pointer should be freeded, and set to NULL prior to the XTPShortcutManager()->DoPropExchange(&secShortcuts,th is); call resetting the accelerator pointer.

Try to move this code to LoadFrame as it done in DesignerSample.