Forum

Could you explain to me exactly what the (bool bInnerHalfSplit ) parameter does of the CExtControlBar::DockControlBar function. I read your docs many times and it is still unclear to me. Thanks

I am having two problems with setting up my inital docking states of my resizable controlbars.

Problem #1. See image ftp://ftp.hash.com/pub/misc/currentinitialstate.jpg. To set up the 3 windows that are docked on the left I did the following.

// Dock Property Bar
m_wndNewPropertyBar.SetInitDesiredSizeVertical(CSize(200, 200));
m_wndNewPropertyBar.SetInitDesiredSizeHorizontal(CSize(200,200));
m_wndNewPropertyBar.SetInitDesiredSizeFloating(CSize(200,300));
m_wndNewPropertyBar.DockControlBar(AFX_IDW_DOCKBAR_LEFT, 1, this, false );

// Dock Pose bar in Property Bar
m_wndPoseBar.SetInitDesiredSizeVertical(CSize(200, 200));
m_wndPoseBar.SetInitDesiredSizeHorizontal(CSize(200,200));
m_wndPoseBar.SetInitDesiredSizeFloating(CSize(200,300));
m_wndNewPropertyBar.DockControlBarIntoTabbedContainer( &m_wndPoseBar, -1, this, false);

RecalcLayout();

// Dock Project Bar
m_wndProjectBar.SetInitDesiredSizeVertical(CSize(200,500));
m_wndProjectBar.SetInitDesiredSizeHorizontal(CSize(1000,200));
m_wndProjectBar.SetInitDesiredSizeFloating(CSize(200,500));
m_wndNewPropertyBar.DockControlBar(&m_wndProjectBar, true, true, this, false);

The m_wndProjectBar:SetInitDesiredSizeVertical(200, 500) seems to have no effect on making this panel take up the majority of the left dock site like shown in: ftp://ftp.hash.com/pub/misc/desiredinitialstate.jpg

Problem #2. I have the timeline dockedas followes:
m_wndTimeLineBar.SetInitDesiredSizeVertical(CSize(300,500));
m_wndTimeLineBar.SetInitDesiredSizeHorizontal(CSize(500,200));
m_wndTimeLineBar.SetInitDesiredSizeFloating(CSize(1000,200));
m_wndTimeLineBar.DockControlBar(AFX_IDW_DOCKBAR_BOTTOM, 2, this, false );
m_wndTimeLineBar.AutoHideModeSet( true, false, false, true );

My desired dock state would be at the bottom, but not under the controlbars that are docked at the left (wndNewPropertyBar, wndPoseBar). To obtain this I gave a Circle of 2. When not in AutoHide mode it is exactly correct. But when in AutoHide mode it always takes up the complete bottom docksite. Is it possible to get what I want?

Dear Daniel,

According to the code provided, you are docking m_wndProjectBar to m_wndNewPropertyBar in the same column. But m_wndNewPropertyBar is already part of the tabbed container. That is why you get heights not fitting what you want. Please first dock "Project Workspace", then dock "Properties", and finally dock "Pose.." to the same tab-container.

Now let’s get to the auto-hide tabs. The outer layer (a.k.a. docking circle #0) of a frame window is occupied by fixed-size control bars (toolbars, menu bars, etc.). The second layer may be occupied by auto-hide tabs (the unnumbered circle). Other inner layers (a.k.a. docking circles with numbers greater than or equal to 1) are used by resizable bars. This design is essential and it is important to implement Visual Studio .NET docking mechanism. The auto-hide tabs could not be placed inside resizable bar layers. But you can make some of your bars similar to MS Office XP’s Task Pane window. This is demonstrated in the FixedSizePanels sample. Such bars are still resizable and they are docked in the outer layer (between toolbars, outside autohide tabs) but cannot be auto-hidden.

I still have problems with the inital desired height on my m_wndProjectBar. I switch to how you recommended, but I can’t dock the m_wndProjectBar first because because I want it on top. If I dock it first then dock "Properties", the "Properties" control bar is on top which isn’t desired.

So here is my new code:
// Dock Property Bar
m_wndNewPropertyBar.SetInitDesiredSizeVertical(CSize(200, 200));
m_wndNewPropertyBar.SetInitDesiredSizeHorizontal(CSize(200,200));
m_wndNewPropertyBar.SetInitDesiredSizeFloating(CSize(200,300));
m_wndNewPropertyBar.DockControlBar(AFX_IDW_DOCKBAR_LEFT, 1, this, true );

// Dock Project Bar
m_wndProjectBar.SetInitDesiredSizeVertical(CSize(200,500));
m_wndProjectBar.SetInitDesiredSizeHorizontal(CSize(300,200));
m_wndProjectBar.SetInitDesiredSizeFloating(CSize(200,500));
m_wndNewPropertyBar.DockControlBar(&m_wndProjectBar, true, false, this, true );

// Dock Pose bar in Property Bar
m_wndPoseBar.SetInitDesiredSizeVertical(CSize(200, 200));
m_wndPoseBar.SetInitDesiredSizeHorizontal(CSize(200,200));
m_wndPoseBar.SetInitDesiredSizeFloating(CSize(200,300));
m_wndNewPropertyBar.DockControlBarIntoTabbedContainer(&m_wndPoseBar, -1, this, false);


But this still has the same problem. My "Project Workspace" bar is smaller than the "Pose/Properties" bar which is not what I specified in the SetInitDesiredSizeVertically calls.

Dear Daniel,

Please make one small improvement in your code snippet: In this line:
m_wndNewPropertyBar.DockControlBar(AFX_IDW_DOCKBAR_LEFT, 1, this, true );
change last parameter to false.

The false was actually how I had it originally which didn’t work either. If I use a false for the last parameter the when I dock the m_wndPropertBar it will force the m_wndPropertyBar to be docked to the right, rather than above. See ftp://ftp.hash.com/pub/misc/WrongInitialState.jpg.

ftp://ftp.hash.com/pub/misc/WrongInitialState.jpg

I currently handle the OnExtMenuPrepare registered message to alter my menu dynamically. The current menu resource has only one item in the popup. I insert more items int the popup on the fly. I use the command manager CmdSetup routine to add the new command. I see the items in the menu as I would expect. However, when the customization dialog is displayed the list displays only the one item with the original text. Not the item’s text that I changed it to and the other items I have created are not displayed either. Is there a way to do this? Any help/suggestions would be appreciated.
Thanks

Dear David,

The OnExtMenuPrepare handler is only called if your application is not in the Customize mode. This is absolutely correct behavior of the popup menu. For example, if you insert a paint-brush bitmap into MS Word and then select object, you may note that the Edit/Object menu (in your Word application) contains dynamically constructed items corresponding to bitmap operations. Then if unselect the bitmap by selecting, for example, a piece of text in the document, the Edit/Object menu will become just a disabled item.

Please note: the MS Word’s Edit/Object dynamic submenu is not accessible in the customize mode at all.

I am creating menus dynamically in my code. I would like to have these items appear in the cusomization dialog when the user wants to customize the menu. I am having the very same issue as a previous post (Guillaume Provost Aug 21, 2003). Any help would be appreciated.
Thanks

Dear David,

To add customizable commands, you should register them in the command manager first. Then you may insert them into any command category that are displayed in the Customize dialog.

To register a command in the customize category, just invoke:

UINT nCmdID = . . .
CExtCustomizeSite::CategoryUpdate(
		"Category name", // New category created automatically
		& nCmdID,
		1
		);

I have one item in the menu resource. I implement ItemInsertCommand to create the new additional menu items. Then call CategoryUpdate with an array of command ids which I just added. The menus are visible but in the customization dialog only the first item is displayed.
When i pull down the menu item while customizing the menus. The menus I had just created with ItemInsertCommand are not visible. I have tried updating the CustomizedTreeNode but I am seeing some odd behavior. Any help/assistance would be appreciated.
Thanks

Is there a way to have Hide/Show Control Bars menu item added to my own menu through your current system? Also I would like to add the Add/Remove buttons menu item to my own menu popup also for one specific toolbar? Is this possible?

For Instance when I right click on a tool bar I would like to have a menu that looks like this:

Allow Docking
Hide
Show/Hide Panels->(All Panels shown here)
Add/Hide Buttons-> (Only have the buttons for this Toolbar here)

Dear Daniel,

The feature you are requesting is possible to implement with Prof-UIS, but first we need to learn whether toolbars and menus in your project are customizable.

All Toolbars and Menus are customizable. What I am trying to do is have the chevrons only visible when absolutely needed. They are only really necessary if I can not hit all visible buttons on the toolbar. So with this in mind I would still like the right click context menu of a toolbar to act similary as the menu on the chevron did. Currently the right click menu on a toolbar is nothing more than a list of controlbars to hide and show. I still want that but under a popup menu called "Show and Hide" like the chevron menus has. I also want the Add/Remove button popup to, but I don’t want a list of all the toolbars on this dock site, I just want the list of buttons for the toolbar that envoked the context menu. So if my chevron is hidden I can still right click on a toobar and get all the same functionality. In fact I will also change the chevron menu to be identical to the right click menu, except the chevron menu will have hidden buttons too. I hope this clarifies my intentions. Thanks a lot. Everything is coming along nicely.

I have been having problems with the states of the windows reloading correctly. See ftp://ftp.hash.com/pub/misc/StateSet.jpg and ftp://ftp.hash.com/pub/misc/StateReload.jpg. One of the problems I see is that the height on the autohide window states are wrong. If I tack the window and retack the window back into auto hide mode it is correct. I’m not sure what I’m doing wrong with the Project workspace window and Property window. One thing I know is I haven’t set up the initial undocked size of panels, but all these panels are docked. Thanks for all your help. Your product support havebeen incredibly quick and detailed.

I found part of my problem with the auto hide panels. I am working on a fix for it. I was under the assumption that the CExtControlBar would get OnSize messages, which is where I resize my child windows. I realize that there can only be one child window now, and that child window can do all the sizing of its children. The other state reload problems still exist however. Thanks again.

Dear Daniel,

To set the initial docking state of resizable bars in the frame window, the following method of CExtControlBar is always should be used at least once:

	bool CExtControlBar::DockControlBar(
		UINT nDockBarID,
		UINT nCircleNo,
		CFrameWnd * pDockSite = NULL,
		bool bRecalcLayout = true
		);

The nCircleNo parameter for any resizable bar should be greater than or equal to 1. We believe this is the source of the problem.

I’m looking for a way to modify menu items in the chevrons of the toolbars. What I am dealing with is there are toolbars listed in the Hide/Show and Customize Buttons section of the chevron menu that I do not want listed here, but I do want thenm listed when a user goes to the Customize dialog. How do I obtain a handle to this menu. Also I would be just as happy to have the Hide/Show and Customize Buttons menu removed all together and have the chevron menu only appear when there are buttons not visible. This would save interface space and the user can still hide and show toolbars by right clicking.

Dear James,

It is possible to modify any Prof-UIS menus on-the-fly, including chevron menu. Prof-UIS sends the CExtControlBar::g_nMsgConstructPopupMenu registered message to the frame window. WPARAM is pointer to CExtControlBar::POPUP_MENU_EVENT_DATA structure which describes type of the CExtPopupMenuWnd object to be constructed dynamically. Frame window receives this message two times for each type of menu. First time, the menu object is empty and frame window may construct it starting from scratch. If frame window returns not-zero value - framework will use the constructed menu as is. In other case, when zero returned first time, frame window receives this message again, but popup menu already constructed and contains default items. Second message can be used to modify default menus. This technique used by the CMainFrame::OnConstructPopupMenuCB() method of the ProfStudio example. Implementation rules are not very complicated:

1) Please add this line to your frame window class definition:
afx_msg LRESULT OnConstructPopupMenuCB( WPARAM wParam, LPARAM lParam );

2) Then add this line to your frame message map:
ON_REGISTERED_MESSAGE( CExtControlBar::g_nMsgConstructPopupMenu, OnConstructPopupMenuCB )

3) your message handler should look like this:

LRESULT CMainFrame::OnConstructPopupMenuCB(
WPARAM wParam, LPARAM lParam )
{
	ASSERT_VALID( this );
	lParam;
CExtControlBar::POPUP_MENU_EVENT_DATA * p_pmed =
		CExtControlBar::POPUP_MENU_EVENT_DATA::
			FromWParam( wParam );
	ASSERT( p_pmed != NULL );
	ASSERT_VALID( p_pmed->m_pPopupMenuWnd );
	ASSERT_VALID( p_pmed->m_pWndEventSrc );
	if( p_pmed->m_nHelperNotificationType ==
		CExtControlBar::POPUP_MENU_EVENT_DATA
			::__PMED_??? )
	{
		if( p_pmed->m_bPostNotification )
			return 0;
// construct your menu here
// (use p_pmed->m_pPopupMenuWnd object)
		return (!0);
	}
	return 0;
}

Type of the popup menu is described by p_pmed->m_nHelperNotificationType. Here is the list of all the menu types:

• __PMED_DOCKBAR_CTX - dockbar context menu


• __PMED_CONTROLBAR_CTX - any control bar context menu (client area)


• __PMED_CONTROLBAR_NC_CTX - any control bar context menu (non-client area)


• __PMED_STATUSBAR_CTX - statusbar context menu


• __PMED_AUTOHIDESLIDER_CTX - autohide slider window context menu


• __PMED_MINIFRAME_NC_CTX - miniframe context menu (non-client area)


• __PMED_MDICLIAREA_CTX - mdi client area context nenu


• __PMED_MDITABS_CTX - mdi-tabs window


• __PMED_AUTOHIDETABS_CTX - autohide-tabs window


• __PMED_DYNCBCTABS_CTX - dynamic control bar container tabs window


• __PMED_CONTROLBAR_NCBTNMENU_TOP - control bar nc-area-menu-button - top level


• __PMED_CONTROLBAR_NCBTNMENU_BARS - control bar nc-area-menu-button - control bars list


• __PMED_CTXEXPBTN_TOP - content expand button(chevron) - top level


• __PMED_CTXEXPBTN_APPEND - content expand button(chevron) - append to buttons list


• __PMED_CTXEXPBTN_BARS - content expand button(chevron) - control bars list

To modify the chevron button behavior (its visibility) you should use your own button class derived from CExtBarContentExpandButton and override IsVisible() virtual method (return value should depend on item count in the CExtBarContentExpandButton::m_buttons array of buttons hidden in the chevron). To make toolbars use your chevron button you also should use your CExtToolControlBar-derived class and override the OnCreateBarRightBtn() method. It just should return new CExtBarContentExpandButton object.

Please do not hesitate contact us if you will come across with any difficulties.

Thanks for all your help. I was able to modify the menus and hide the Chevron menus when needed. However one of my reasons for hiding the Chevron menus was for real estate reasons, and I noticed the toolbars seem to be the same length regardless. See ftp://ftp.hash.com/pub/misc/ButtonSpace.jpg

Hi, I want to use the WinXP DrawThemeBackground() function to draw a checkbox ie. BP_CHECKBOX. I have found that the paint manager has ptrs to the various theme api functions. How do I use m_pUxApi_DrawThemeBackground() etc. in my code. I’m sure this is simple.

Also how can I detect whether I can use theme api functions vs. the older non-XP drawing functions.

For some reason the last pane in my status bar draws its borders wrong. It would appear that it is always off by the width of the gripper. Do you know of something I might have initializd wrong. It would appear that my code matches all the sample apps. The call to GetItemRect( nItem, rc ) does return an incorrect size. It isn’t the size that I set the pane to. See picture at:
ftp://ftp.hash.com/pub/misc/statusbar.jpg
Thanks,
Dan

I think I may be missing something, but it ould seem by default that the m_sMenuText should be initially set to the m_sToolbarText, or if m_sMenuText is empty the menu drawer should use the m_sToolbarText. The sToolbarText is exactly the text I would like to see if a user drug a button onto a menuitem. By default right now I only get an Icon for all my buttons when the sToolbarText is exactly what I would have like to seen with the icon in the menu anyways. I believe the reverse works fine, if I drag a menu item to a toolbar I get the sMenuText is I do not have m_sToolbarText. Am I missing something? Thanks in advance!

I would think that in the void CExtStatusControlBar::OnPaint() function what it should check each panes style for SBPS_NOBORDERS before the call to g_PaintManager->PaintControlBarBorders( dc, _pcbbd );

Is there a way to associate an icon with the panes in the statusbar. I would like a visual representation of what the panes are. Also how would I go about adding a progress control to a statusbar so I can activate it when a progress needs to be presented. I would imagine that when the progres control is active it would also have its own paints for the description of what is happening

Is there a way to tell if all buttons are visible on the tool bar and not in the drop down menu. At start up I would like to position some of the tools bars on their own line if not all the buttons are visible. This is only for the first time the app is ran, after that I will use the serialized state.

When I turn on the Auto Hide button then move off the control bar shouldn’t it hide. It appears to think it already is. Is this a bug?

We try to make the behavior of the auto hide button similar to that of Microsoft Visual Studio. Please give us more details on the misbehavior you imply.

When I untack the button to allow the ControlBar to auto hide It would seem that the instance my mouse moves off of the controlbar window it should then hide itself, which it doesn’t unless I move over the auto hide tab. See ftp://ftp.hash.com/pub/misc/autohide.avi for an example.

I am converting all my resizable control bars over to CExtControl, but have run into problem. They are using multiple controls, and therefore the ASSERT fails in OnRepositionSingleChild().

It looks like I can set m_bReposSingleChildMode to FALSE to avoid the algorithm, but the member variable is private.

I assume from this that I’m supposed to use the Prof-UIS resizable dialog and place all my controls on top of that, but I already have all that coded with my own resizable control bar class and migrating all this is going to take me a couple of hours just to convert one of my 10 control bars.

If I add a member function to set the m_bReposSingleChildMode property to false, I get around the ASSERT. Can you guys add this in the next version, or maybe instead of ASSERTing, could it be changed to check and see if there is only one child window. If so, resize, otherwise skip algorithm.

Maybe I’m missing the concept but this would seem better because it would function the same way with Prof-UIS and support multiple controls on the control bar. Only a small suggestion. I like the framework though.

I tried converting one of my applications over to use CExtMenuControlBar. Unfortunately, I’m getting some strange behavior with it.

The application is an MDI doc/view. (With multi-document templates)

First, the menu bar does not properly redraw between different document types. (It’s as if it’s missing the invalidate when switching document types)

Second, the menu bar does not span across the screen like it does in ProfStudio, FunnyBar demos, etc. Meaning, the light gray area only takes up the portion of the bar that’s actually used instead using the complete width of the main frame.

Third, if I try to undock the bar with click and drag on gripper, an ASSERT fails in objcore.cpp, line 63. AfxStaticDownCast() It looks like it fails because the object type is CDockBar instead of CExtDocOuterBar. CExtControlBar does a STATIC_DOWNCAST in CExtControlBar::InternalDraggingState_t::_DoFixed_BasicAdjustment

I tried creating a simple MDI application, and everything works fine. So there must be something I doing wrong, or some kind of special handling that my app does that confuses Prof-UIS.

I’m trying to figure this out and hope someone might know what I’m doing wrong and point me in the right direction. I’ve created the menu according to FunnyBars demo. (Nothing special; just a simple create, EnableDocking, DockControlBar, and the handler for PreTranslateMessage)

Any help appreciated. Thank you. Kind regards,
Logan

Dear Logan,

To help you we need to take a look at the following source code:

• MainFrm.h and MainFrm.cpp files


• CYourApp::InitInstance() method


• names of the base classes for all documents and views

The complete project’s source code would be more convenient for us.

Just an FYI: using CExtControlBar::FrameEnableDocking fixed the second and third problem that I mentioned in my first post.

Is Prof-UIS framework capable of working hand-in-hand with a mix of regular MFC control bars and Prof-UIS bars, or am I required to convert all of my control bars over to use Prof-UIS based control bars?

Right now, there does not seem to be a way. I will get an ASSERT if I DockControlBar with regular MFC control bars after FrameEnableDocking is called. If I call DockControlBar before the FrameEnableDocking--just for regular MFC bars--they disappear.

Dear Logan,

In Prof-UIS 2.21 we announced Persistent Affixment Algorithm for the fixed-size control bars (toolbars and panel bars). This algorithm enables Prof-UIS control bars to behave similar to the command bars appeared in the latest Microsoft products (Office 2003 and Visual Studio .NET). That requires keeping additional affixment data for each fixed-size bar. So, starting with version 2.21, Prof-UIS is compatible with any standard CControlBar that is not enabled to be dockable by invoking CFrameWnd::EnableDocking() (e.g., the status bar or a non-dockable toolbar).

You can use CExtToolControlBar to replace any kind of CToolBar. The CExtPanelControlBar class is appropriate for replacing any kind of the dialog bar (please take a look at the FixedSizePanels). Any other bar including a splitter window emulator can be implemented with CExtControlBar, which may be either in a fixed mode (e.g., MS Office Task Pane) or in a resizable mode (e.g., the VS .NET dockable pane). In any case, you can remove the caption, modify the buttons, disable a floating state, and whatsoever you want.

Please don’t worry about fixing my problem. I guess what I really want to know is how one is supposed to install Prof-UIS in an existing application. If you have documentation already, please let me know and I will read it.

The Prof-UIS AppWizard is nice and easy to use, and therefore makes Prof-UIS ideal when creating new applications, but for an existing application, it isn’t clear what functions I am required to call to initialize your framework. Or what Prof-UIS expects to see. (For example, I see you call ActivateFrame() in InitInstance instead of ShowWindow(), but I’m not sure why you do it that way)

Initially, I was under the impression that using Prof-UIS menus was as simple as changing CMenu to CExtMenuControlBar. Is this true? Am I required to call CExtControlBar::FrameEnableDocking. If I call these, all my non-Prof-UIS control bars cause ASSERT errors. If I remove the FrameEnableDocking() call, the menus work, but with the problems I described above.

Thank you for your help.

Dear Logan,

Prof-UIS really requires CExtControlBar::FrameEnableDocking() to be invoked instead of CFrameWnd::EnableDocking(). You can read about this in the Docking Mechanism Explained article.

The CFrameWnd::ActivateFrame() method overriding is not needed. But it is convenient to use it for restoring position of the frame window. In all the Prof-UIS samples ActivateFrame() used to set loaded window postion when it invoked first time.

I probably should have taken a closer look at the docking mechanism article beforehand as it has more information than I initially thought.

At this point my application is working great without any functional problems. (Only some minor graphical issues)

I’m pleased with the framework overall. (Especially the examples) It would be great (for new users of Prof-UIS) if the naming conventions were more MFC-like, (i.e. GetItemRect() instead of ItemGet()->ItemRectGet()) but everything is consistent and it is probably too late to change that now anyway. :-)

Thank you for the information.

This problem can be duplciated with the ProfStudio example.

• Run ProfStudio in the debugger (I deleted the registry entries first so that the window positions/settings would be the default)


• Drag the "Command Window" tab from the docked pane directly under MDI window and make it a floating window.


• Drag the "Properties" tab from the docked pane directly under MDI window and dock it to the floating "Command Window" window. It doesn’t matter if you dock it as a tab or as a regular pane.


• Drag the floating window with the "Command Window" and "Properties" panes and try to dock it back to the original pane under the MDI window, so that they become tabs again.

The program will crash with the following message:

Unhandled exception at 0x00582f60 (ProfUIS223nd.dll) in 
ProfStudio-nd.exe: 0xC0000005: Access violation reading location 
0xfeef014a.

in ExtControlBar.cpp, _DraggingStart(), at line 8692.

It looks like the m_hWnd variable is no longer valid.

As a follow-up, I put the following code at line 8687, and it fixed the problem

if (!::IsWindow( m_hWnd ) || !::IsWindow( msg.hwnd ))
   return;

I’m trying to put a CExtComboBox control on a toolbar, using the code from the ProfStudio example. The toolbar is not expanding to fit the control though - instead the combobox extends over any following buttons, and is truncated at the end of the toolbar. I can’t for the life of me figure out what’s different between what I’m doing and what is being done in the ProfStudio example. This is the code I’m using:

   CString strTitle;
   strTitle.LoadString(IDS_VIEWTOOLBAR);

   if ( !m_wndViewToolBar.Create(strTitle, this, ID_VIEW_VIEWTOOLBAR) || 
        !m_wndViewToolBar.LoadToolBar(IDR_VIEWTOOLBAR))
   {
      TRACE0("Failed to create View Toolbar\n");
      return(FALSE);      // fail to create
   }
   if (m_comboView.Create( WS_CHILD | CBS_HASSTRINGS | CBS_DROPDOWNLIST | WS_VISIBLE,
                           CRect(0,0,200,300),
                           &m_wndViewToolBar,
                           ID_VIEW_BS_TYPECOMBO))
   {
      VERIFY( m_wndViewToolBar.SetButtonCtrl( m_wndViewToolBar.CommandToIndex( ID_VIEW_BS_TYPECOMBO ),
                                              &m_comboView ));

      m_comboView.SetFont( CFont::FromHandle( (HFONT)::GetStockObject(DEFAULT_GUI_FONT) ));
      m_comboView.SetItemHeight( -1, m_comboView.GetItemHeight( -1 ) - 1);

      m_comboView.AddString( _T("Win32 Debug") );
      m_comboView.AddString( _T("Win32 Release") );
      m_comboView.AddString( _T("Win32 Unicode Debug") );
      m_comboView.AddString( _T("Win32 Unicode Release") );
      m_comboView.SetCurSel( 0 );

   }

   m_wndViewToolBar.EnableDocking(CBRS_ALIGN_ANY);

Any ideas as to what’s wrong? Maybe I’m not initializing a property somewhere? I traced into CExtBarButton::CalculateLayout() and it is recognizing that it’s a control and calculating the active size correctly.

Dear Kishore,

We suppose the problem in question hides somewhere in CMainFrame::OnCreate(). Please let us take a look at the complete code of the method or send us your project.

Thanks for the quick response. Sorry I didn’t get back to you sooner, but I was pulled off to fight a fire somewhere else.

I did poke around a little, and found that the problem is caused by enabling the customization option. I was able to duplicate it in the ProfStudio example, by doing the following.

1) Added

#include "ExtCustomize.h"

to MainFrm.h at line 42 2) Added

class CExtCustomizeSite;

to MainFrm.h at line 52;

3) I changed line 97 of MainFrm.h by adding

 , public CExtCustomizeSite

to the end of the class declaration. 4) Added the following code to MainFrm.cpp, at line 2164:

	VERIFY( CExtCustomizeSite::MenuInfoAdd( this, 
                                           _T("Default"), 
                                           IDR_MAINFRAME, 
                                           true,
                                           false,
                                           RUNTIME_CLASS( CMainFrame )));
	if( !CExtCustomizeSite::EnableCustomization( this ) )
	{
		ASSERT( FALSE );
		return -1;
	}
	CExtCustomizeSite::CategoryUpdate( IDR_MAINFRAME );

This caused the toolbars to stop sizing to fit the comboboxes. Any ideas on how I can get around the problem?

Hi,

Sorry for the delay with this answer.

Customizable toolbars should not have combo-box windows inside. The CExtComboBox window cannot be resized in the Customize Mode. It cannot be dropped onto menu either.

For that, please use build-in combo-field items. The StyleEditor sample demonstrates their usage. Please note that such combo items feature automatic content synchronization between different copies of one combo-command. Send send us your CMainFrame’s class source code (.H and .CPP) files so that we can help you fix the problem.

Reposting this because I’m not sure it got through before - I was logged off when I hit "post".

I used the example in the FAQ to modify the File menu in my app, and it works great. However, there’s a sub-menu off the file menu that I need to modify as well, and I don’t get the g_nMsgPrepareMenu message for the submenu. Looking through the source code, I found that, in ExtPopupMenuWnd.cpp, _TrackPopupMenu(), there is code checking to see if the menu being tracked is a toplevel menu - if it isn’t, the routine doesn’t send the message. If I comment out the code (and the corresponding ASSERTs) I then get the message and everything *seems* to work fine. Could you elaborate on the reason why the toplevel checks are in there and what repercussions there may be by removing them?

Hi,

CExtPopupMenuWnd implements a menu hierarchy for one visible popup menu. It sends the g_nMsgPrepareMenu message for the top menu only to perform complete initialization of the popup menu tree (not only a single level). The hierarchy of CExtPopupMenuWnd objects exists until the menu is tracked. Only visible objects have real HWNDs. That described menu design.

We believe that the menu structure should not be changed while the popup menu is being tracked. So, there is no reason to reinitialize each popup menu every time it becomes visible. Of course, this causes some inconvenience: A universal the universal message handler for g_nMsgPrepareMenu needs to be recursive. There are no potential problems with your code modification. You just changed menu design.

So the way to handle this within the intended design would be to modify any and all submenus at the time I get the toplevel menu notification?

Hi, When you close an application that has a hiden floating window, then when the application next starts you see the window appear briefly. This is a little disconcerting and it would be nice if it didn’t happen.

Rgds, Neville

Hi at present the state of MDI child windows is not retained along with the other window informationm across invocations of an application. For example if I’ve maxmimized an MDI window, then next time the app starts I would like it to be maximized again. Ideally this should track the minimized/restored/maximized state a) when the application is closed, b) when the last MDI window is closed. Then the next an MDI window is opened it will restore to this LRU state. Is this something you could add to the Prof-UIS framework, or should I write code to do this?