Forum

Hi Customer Support,

I know this is very simple question but I am having problem with it. I started my project by adding code in your sample application DrawView. Now, I am almost finished with my project but I want to delete the File New Button from the toolbar and also from the Menu bar. Removing it from the menu bar was easy...However, I am having difficulty removing it from the Toolbar. You have created a 256 color toolbar and I like it and would like to keep it the way it is...but replace the New File (first toolbar in IDR_MAINFRAME) with something else or just remove it.

I appreciate your help.

Saroj

Prior to ProfUIS 2.31, implementing CMainFrame::OnConstructPopupMenuCB() would override default r/click popup menu behvaiour.
Now, with c2.31, popup menus are appearing again. I can trace to: CExtDynamicBarHookSink::OnHookWndMsg().

Can you please suggest a good technique to gain control of pop-up menus again?

I interested disabling all your r/click pop-ups, except the following scenarios:
1. R/click in NCarea (only!) of CExtDynamicControlBar, when in __EDBS_FLOATING, __EDBS_DOCKED, and __EDBS_AUTO_HIDDEN states
2. r/click in MDI tabs of CExtDynamicControlBar when they are in __EDBS_DOCUMENT state.
3. r/click in vacant toolbar area

I’m sure other readers would also be interested in the more general approach/technique of how r/click should now be handled.

Dear Dave,

The behavior of the build-in popup menu control was not changed. You should be able to do with it everything you need as it is done in ProfStudio sample. As you know the CExtControlBar::g_nMsgConstructPopupMenu registered windows message passes a pointer to the CExtControlBar::POPUP_MENU_EVENT_DATA object in the WPARAM parameter. This object allows you to cancel pop-up menu tracking. If you do not need to display the pop-up menu on the screen, just remove all the items in pop-up menu. Here is an approximate solution:

LRESULT CMainFrame::OnConstructPopupMenuCB(
    WPARAM wParam, LPARAM lParam )
{
    ASSERT_VALID( this );
    lParam; // unused parameter
    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 );
    ASSERT(
        p_pmed->m_pWndEventSrc->
            GetSafeHwnd() != NULL
        );
    ASSERT( ::IsWindow(
        p_pmed->m_pWndEventSrc->
            GetSafeHwnd())
        );
    if(   p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_DOCKBAR_CTX
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CONTROLBAR_NC_CTX
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_AUTOHIDESLIDER_CTX
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_MDITABS_CTX
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_DYNCBCTABS_CTX
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CONTROLBAR_NCBTNMENU_TOP
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CONTROLBAR_NCBTNMENU_BARS
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CTXEXPBTN_TOP
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CTXEXPBTN_APPEND
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CTXEXPBTN_BARS
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_CONTROLBAR_NCBTNMENU_DYNSTATE
      ||  p_pmed->m_nHelperNotificationType ==
            CExtControlBar::POPUP_MENU_EVENT_DATA::
                __PMED_TAB_PAGE_CONTAINER_TABS_CTX
        )
        return 0;
    VERIFY( p_pmed->m_pPopupMenuWnd->ItemRemove() );
    return (!0);
}

Perfect, just what I needed - thanks!

I found this chunk of code in another posting, should I also use it in the code you’ve provided above? If so, where? Can you explain its purpose?

if( p_pmed->m_bPostNotification )
{
return 0;
}

Thanks!

The lines of code above have nothing to do with your task and you should not use this code. Each build-in menu’s/submenu’s construction message is sent twice to the main frame window. At first, the menu is empty and the p_pmed->m_bPostNotification flag is set to false. Here you can construct appropriate menus from scratch and return a non-zero value to prevent the second message to be sent. Otherwise, return zero. The second time, the menu is constructed by default and p_pmed->m_bPostNotification is set to true. In this case you can modify the default built-in menu. In any case, if the final menu is empty, it is not displayed.

Dear support team,

is it possible to embed a CExtPopupMenuWnd as a permanent child in a CExtResizableDialog?

The menu will have no further popup entries, so the size will be fix.

Best regards.

Axel

Toolbar buttons with drop-down menus don’t have their menu disabled when the button is disabled. ie. Click on the drop own arrow and the menu is displayed even though the button is disabled.

In my CMainFrame::OnExtMenuPrepare() function I tried adding:

pData->m_bMenuCanceled = true;

but this causes an exception because m_pPopup is deleted twice.

Is there some way I can stop the menu from appearing when the button is disabled?

It’s not a bug at all. We believe that, if such a button is disabled, in all cases, displaying its pop-up menu should be disabled. For example, Microsoft Office applications do produce menus for disabled buttons (of course the items in such menus are reasonably disabled). But we agree with you that in some cases it would be better to disable producing such a menu at all (like Back and Forward buttons). Here is how it can be done.

Create a CExtBarButton-derived class and override the CanBePressedInDisabledState() virtual method which should do nothing except return false. Now you need to use this button in your toolbars. Create your own CExtToolControlBar-derived class and override the OnCreateBarCommandBtn() virtual method that creates a new instance of your button. Finally, if your application is customizable, please override the CExtCustomizeSite::OnUserBarCreate() virtual method. This method creates instances of your toolbar type. Use the method body from the original method and only modify the code responsible for creating this button.

Following advice in Forum posts to control which buttons are displayed in CExtDynamicControlBar, I override CExtDynamicControlBar::OnNcAreaButtonsReinitialize().

However, if I tab-dock any control bars, the following method gets called, and creates buttons that I didn’t want. Can you suggest how I can get around this problem?


void CExtDynamicTabbedControlBar::OnNcAreaButtonsReinitialize()
{
    ASSERT_VALID( this );
INT nCountOfNcButtons = NcButtons_GetCount();
    if( nCountOfNcButtons > 0 )
        return;
    NcButtons_Add( new CExtDynamicBarNcAreaButtonClose(this) );
    NcButtons_Add( new CExtDynamicBarNcAreaButtonAutoHide(this) );
    NcButtons_Add( new CExtDynamicBarNcAreaButtonMenu(this) );
}


Here’s a sample call-stack when I perform some code-driven tab-docking (as opposed to drag-n-drop), if it is of any use to you.


CExtDynamicTabbedControlBar::OnNcAreaButtonsReinitialize() line 4944
CExtControlBar::OnNcCalcSize(int 1, tagNCCALCSIZE_PARAMS * 0x0012ebe8) line 6753 + 22 bytes
CExtDynTabControlBar::OnNcCalcSize(int 1, tagNCCALCSIZE_PARAMS * 0x0012ebe8) line 1177
CWnd::OnWndMsg(unsigned int 131, unsigned int 1, long 1240040, long * 0x0012e9e4) line 1950
CWnd::WindowProc(unsigned int 131, unsigned int 1, long 1240040) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 131, unsigned int 1, long 1240040) line 480 + 20 bytes
CExtControlBar::WindowProc(unsigned int 131, unsigned int 1, long 1240040) line 6043
AfxCallWndProc(CWnd * 0x01fe2f70, HWND__ * 0x003107f8, unsigned int 131, unsigned int 1, long 1240040) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x003107f8, unsigned int 131, unsigned int 1, long 1240040) line 368
AfxWndProcBase(HWND__ * 0x003107f8, unsigned int 131, unsigned int 1, long 1240040) line 220 + 21 bytes
USER32! 77e11ef0()
USER32! 77e13869()
USER32! 77e1677c()
NTDLL! 77f9ff57()
CExtControlBar::DockControlBarIntoTabbedContainer(CExtControlBar * 0x01fd1d10 {CToolWnd hWnd=???}, int -1, CFrameWnd * 0x01fb77d8 {CMainFrame hWnd=???}, unsigned char 1) line 15824

Perhaps I should also mention: the unwanted buttons go away once the affected control bars are no longer tab-docked.

Hello,

I just got a new computer and installed Windows XP Professional and added SP2.
I then tried to install ProfUIS (a couple of different versions) and get the following error message after the wizard appears to get past the end and perform a some sort of registration:

The wizard was interrupted before Professional User Interface Suite 2.30 could be completely installed.

The system has not been modified. To install this program at a later time, run the installation again.
Click Finish to exit the wizard.

Any help is appreciated,
David

Well, I rebooted and it worked. I must have installed something that needed a reboot after sp2. I also found that a cygwin file /bin/link was conflicting with Visual C++ .NET 2003’s link and I had to rename it.
Thanks,
David

I used ProfUISAppWizard to create a new ProfUIS project. Then without modify anything I built it and tried to start it but - "This Application has failed to start because ProfUIS230md.dll was not found. Re-installing the application may fix this problem. "

Reinstalling didn’t help.

I tried to add a similiar project into the sample solution - the same bad message.

The projects settings are the same as these projects settings into the sample solution.

Do you have any ideas?

Before using the Application Wizard, please compile the Prof-UIS library. In your particular case, you need to compile it to the MBCS Debug configuration. As a result, you should have the ProfUIS230md.lib and ProfUIS230md.dll files which will allow you to use the library in your projects. You can compile the library manually (with Visual Studio) or with the Prof-UIS Integration Wizard (Visual Studio is used implicitly). Please contact us if you encounter any difficulties.

Thank you for the answer but i think I have compiled it already.

I built and run all sample projects and I had no problems, but if I try to make my own project the bad message appears.  

I have to re-dock toolbars and controlbars many times during runtime (user is allowed to re-configure layout). During this process, I cannot show+hide the mainframe: must leave frame outline, main menu, status bar all visible.

My questions are:

1. If I use pMainFrame->SetRedraw(FALSE), are there any negative effects I need to worry about when re-docking toolbars and controlbars? Or will they re-dock OK? Please keep in mind I am using some of your wild docking techniques, such docking 3 controlbars together, sharing space across one row:

pBarA->DockControlBarInnerOuter( AFX_IDW_DOCKBAR_BOTTOM, false, FRM, true );
pBarB->DockControlBarLTRB( 66, pBarA, AFX_IDW_DOCKBAR_RIGHT, true );
pBarC->DockControlBarLTRB( 50, pBarB, AFX_IDW_DOCKBAR_RIGHT, true );


2. Is ControlBar docking affected by their visibility?
(Toolbar docking is affected by visibility, as we’ve discussed in another forum posting).


3. Is controlBar docking affected by Mainframe->SetRedraw(FALSE)? will their RecalcLayout() still work OK?



I am using:
CExtToolControlBar    // toolbars
CExtDynamicControlBar    // control bars
CExtTabMdiWhidbeyWnd // mdi tabs

Here’s pseudocode of what I’m trying to do:

class CMainFrame : public CMDIFrameWnd, public CExtDynamicBarSite
{
....
}

// hide all toolbars
// hide all controlbars

pMainframe->SetRedraw(FALSE);

// re-dock all toolbars according to new specified layout
// re-dock all controlbars according to new specified layout

// show only desired toolbars
// show only desired controlbars

pMainframe->SetRedraw(TRUE);

We never used the SetRedraw() method with regard to frame windows because it is not needed at all. You can try the StateInFile sample application: save GUI states in several files, load these files and make a conclusion about flickering. The methods for serializing control bars are the same as in case of docking them. There is one thing which may affect flickering in your project. It deals with visibility of a control bar. In case of any window but a control bar, you can use the window style flags and check whether WS_VISIBLE is on. In case of control bars, you need to use the CExtControlBar::IsVisible() method. This is because, the control bar’s window can be visible but, in fact, it may get hidden in some time when the CFrameWnd::RecalcLayout() method is invoked. The same is true for the case when the window is still hidden but in fact somewhere in code it has already forced to be shown and it will become displayed when CFrameWnd::RecalcLayout() is called. This technique (which is used both in MFC and Prof-UIS) effectively eliminates flickering when docking is used. So, the flicker free redocking feature is not based on SetRedraw() method. All CExtControlBar::DockControlBar...() methods have the bRecalcLayout parameter which you can set to false for the flicker free bar redocking.

I’m facing some problems using two CExtRadioButtons in a CExtResizableDialog.

I declared two CExtRadioButton variables, the first one has the Group option set to TRUE. I also declared one variable of type int to be used with the UpdataData() function to set the radio buttons. In the DoDataExchange() function I wrote the following code

DDX_Control(pDX, IDC_RADIO1, m_wndRadio1);

DDX_Control(pDX, IDC_RADIO2, m_wndRadio2);

DDX_Radio(pDX, IDC_RADIO1, m_radioVariable);

Just use the DDX_Radio function first (before using any of the DDX_Control functions) like below:

DDX_Radio(pDX, IDC_RADIO1, m_radioVariable);
DDX_Control(pDX, IDC_RADIO1, m_wndRadio1);
DDX_Control(pDX, IDC_RADIO2, m_wndRadio2);

I’ve tried to put the DDX_Radio function first but it still not working. Soon after I catch the ON_BN_CLICKED message and after having called the UpdateData(true) function my variable is not updated. Besides if I click the second radio button I get two radio buttons switched on and I cannot turn them off.

I hope this can help you. I found out that it’s not working probably because my CExtRadioButtons belongs to a CExtResizableDialog which is child of a CExtTabPageContainerWnd. I’ve tried with another popup CExtResizableDialog and it works. It also works with a CExtResizableDialog  which is child of a CExtResizablePropertyPage.

We tested this case once more and must say that int m_radioVariable is successfully updated when CExtRadioButton variables are children of CExtResizableDialog, which, in turn, is a child of CExtTabPageContainerWnd. We also tested some other cases of windows relationship and found no problems. So, if it’s possible, send us a sample project so that we can quickly help you.

Hi,
When I compile my unicode application in Release mode I get the following errors (see below) - am i missing a compile/linker error that i need to set?

Linking...
MainFrm.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CExtMenuControlBar::SetMdiWindowPopupName(wchar_t const *)" (?SetMdiWindowPopupName@CExtMenuControlBar@@UAEXPB_W@Z)
MainFrm.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CExtControlBar::OnGetBarCaptionText(enum CExtControlBar::e_bar_caption_text_t,class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &)const " (?OnGetBarCaptionText@CExtControlBar@@UBEXW4e_bar_caption_text_t@1@AAV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z)
XPPanel.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CExtControlBar::OnGetBarCaptionText(enum CExtControlBar::e_bar_caption_text_t,class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &)const " (?OnGetBarCaptionText@CExtControlBar@@UBEXW4e_bar_caption_text_t@1@AAV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z)
MainFrm.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall CExtControlBar::Create(wchar_t const *,class CWnd *,unsigned int,unsigned long)" (?Create@CExtControlBar@@UAEHPB_WPAVCWnd@@IK@Z)
XPPanel.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall CExtControlBar::Create(wchar_t const *,class CWnd *,unsigned int,unsigned long)" (?Create@CExtControlBar@@UAEHPB_WPAVCWnd@@IK@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::SerializeState(wchar_t const *,wchar_t const *,wchar_t const *,bool)" (?SerializeState@CExtCmdManager@@QAE_NPB_W00_N@Z) referenced in function "public: virtual int __thiscall CMainFrame::DestroyWindow(void)" (?DestroyWindow@CMainFrame@@UAEHXZ)
MainFrm.obj : error LNK2019: unresolved external symbol "public: static bool __cdecl CExtControlBar::ProfileBarStateSave(class CFrameWnd *,wchar_t const *,wchar_t const *,wchar_t const *,struct tagWINDOWPLACEMENT *)" (?ProfileBarStateSave@CExtControlBar@@SA_NPAVCFrameWnd@@PB_W11PAUtagWINDOWPLACEMENT@@@Z) referenced in function "public: virtual int __thiscall CMainFrame::DestroyWindow(void)" (?DestroyWindow@CMainFrame@@UAEHXZ)
MainFrm.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::CmdSetIcon(wchar_t const *,unsigned int,struct HICON__ *,bool)" (?CmdSetIcon@CExtCmdManager@@QAE_NPB_WIPAUHICON__@@_N@Z) referenced in function "protected: void __thiscall CMainFrame::SetPanelIcon(class CPanelParam)" (?SetPanelIcon@CMainFrame@@IAEXVCPanelParam@@@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: wchar_t const * __thiscall CExtCmdManager::ProfileNameFromWnd(struct HWND__ *)" (?ProfileNameFromWnd@CExtCmdManager@@QAEPB_WPAUHWND__@@@Z) referenced in function "protected: void __thiscall CMainFrame::SetPanelIcon(class CPanelParam)" (?SetPanelIcon@CMainFrame@@IAEXVCPanelParam@@@Z)
MenuBarEx.obj : error LNK2001: unresolved external symbol "public: wchar_t const * __thiscall CExtCmdManager::ProfileNameFromWnd(struct HWND__ *)" (?ProfileNameFromWnd@CExtCmdManager@@QAEPB_WPAUHWND__@@@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: class CExtCmdItem * __thiscall CExtCmdManager::CmdGetPtr(wchar_t const *,unsigned int)" (?CmdGetPtr@CExtCmdManager@@QAEPAVCExtCmdItem@@PB_WI@Z) referenced in function "protected: int __thiscall CMainFrame::OnToolBarButton(unsigned int)" (?OnToolBarButton@CMainFrame@@IAEHI@Z)
MenuBarEx.obj : error LNK2001: unresolved external symbol "public: class CExtCmdItem * __thiscall CExtCmdManager::CmdGetPtr(wchar_t const *,unsigned int)" (?CmdGetPtr@CExtCmdManager@@QAEPAVCExtCmdItem@@PB_WI@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::SetBasicCommands(wchar_t const *,unsigned int *,bool)" (?SetBasicCommands@CExtCmdManager@@QAE_NPB_WPAI_N@Z) referenced in function "protected: int __thiscall CMainFrame::OnCreate(struct tagCREATESTRUCTW *)" (?OnCreate@CMainFrame@@IAEHPAUtagCREATESTRUCTW@@@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: class CExtCmdItem * __thiscall CExtCmdManager::CmdAllocPtr(wchar_t const *,unsigned int)" (?CmdAllocPtr@CExtCmdManager@@QAEPAVCExtCmdItem@@PB_WI@Z) referenced in function "protected: int __thiscall CMainFrame::OnCreate(struct tagCREATESTRUCTW *)" (?OnCreate@CMainFrame@@IAEHPAUtagCREATESTRUCTW@@@Z)
MenuBarEx.obj : error LNK2001: unresolved external symbol "public: class CExtCmdItem * __thiscall CExtCmdManager::CmdAllocPtr(wchar_t const *,unsigned int)" (?CmdAllocPtr@CExtCmdManager@@QAEPAVCExtCmdItem@@PB_WI@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::UpdateFromMenu(wchar_t const *,unsigned int,bool,bool)" (?UpdateFromMenu@CExtCmdManager@@QAE_NPB_WI_N1@Z) referenced in function "protected: int __thiscall CMainFrame::OnCreate(struct tagCREATESTRUCTW *)" (?OnCreate@CMainFrame@@IAEHPAUtagCREATESTRUCTW@@@Z)
MainFrm.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::ProfileWndAdd(wchar_t const *,struct HWND__ *)" (?ProfileWndAdd@CExtCmdManager@@QAE_NPB_WPAUHWND__@@@Z) referenced in function "protected: int __thiscall CMainFrame::OnCreate(struct tagCREATESTRUCTW *)" (?OnCreate@CMainFrame@@IAEHPAUtagCREATESTRUCTW@@@Z)
MenuBarEx.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::CmdRemoveByMask(wchar_t const *,unsigned long,bool)" (?CmdRemoveByMask@CExtCmdManager@@QAE_NPB_WK_N@Z) referenced in function "protected: virtual int __thiscall CMenuBarEx::_UpdateMenuBar(int)" (?_UpdateMenuBar@CMenuBarEx@@MAEHH@Z)
MFCXPGui.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::ProfileSetup(wchar_t const *,struct HWND__ *,class CExtCmdProfile *)" (?ProfileSetup@CExtCmdManager@@QAE_NPB_WPAUHWND__@@PAVCExtCmdProfile@@@Z) referenced in function "public: void __thiscall CMFCXPGuiApp::SetupUiAdvancedOptions(void)" (?SetupUiAdvancedOptions@CMFCXPGuiApp@@QAEXXZ)
MFCXPGui.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall CExtResDlg::Create(wchar_t const *,class CWnd *)" (?Create@CExtResDlg@@UAEHPB_WPAVCWnd@@@Z)
XPPanel.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CExtDynTabControlBar::OnGetBarCaptionText(enum CExtControlBar::e_bar_caption_text_t,class ATL::CStringT<wchar_t,class StrTraitMFC<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > &)const " (?OnGetBarCaptionText@CExtDynTabControlBar@@UBEXW4e_bar_caption_text_t@CExtControlBar@@AAV?$CStringT@_WV?$StrTraitMFC@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z)

My current application properties are:

MFC Statically Linked
ATL Statically Linked
Use Unicode Character Set

Preprocessore defs: WIN32;_WINDOWS;NDEBUG;_UNICODE

I Am using Vis Studio 2003.

Thanks.

Hi,

I want a toolbar button with drop down arrow and list. This would be the same as the Back and Forward buttons in Internet Explorer where you click on the button and the action is executed and you click on the arrow and the list is displayed. Selecting a list item executes the command with the selected item.

Also like these IE buttons I want to dynamically set the button’s tooltip text.

So how can I do both of these things?

Thanks,
Neville

To set tooltip text or any other parameter for a command dynamically, you need to retrieve the CExtCmdItem object from the command manager and set appropriate values:

CExtCmdItem * pCmdItem =
g_CmdManager->CmdGetPtr( strProfileName, ID_SOME_CMD );
ASSERT( pCmdItem != NULL );
pCmdItem->m_sTipStatus = _T("Tip Status");
pCmdItem->m_sTipTool = _T("Tip Tool");

I have worked out how pTBB->SetSeparatedDropDown() along with adding a menu can be used but that isn’t ideal for me.

I would prefer the drop down arrow to work the same as a Toolbar combo box does and call CMainFrame::OnPopupListBoxInitContent() etc.  I need to dynamically build the drop down content.

I’ve seen CExtPopupUndoRedoMenuWnd which is closer to what I want assume this is not appropriate for my needs. I can’t find any documentation for this either.

I also discovered what appears to be a bug. When a button has menu attached and the button is disabled you can still click on the drop down arrow and the menu is displayed.

There is a very simple method to create a toolbar button with a separated drop-down area which is tracking the dynamically created menu.

1) Create a toolbar button with a drop-down menu and assign a menu (e.g.,IDR_DYNAMIC_POPUP_MENU) to it. This menu contains a temporary menu item with a certain ID (e.g., ID_TEMP)

INT nBtnIdx = m_wndToolBar.CommandToIndex( ID_SOME_CMD );
ASSERT( nBtnIdx >= 0 );
CMenu _line_menu;
VERIFY( _line_menu.LoadMenu( IDR_DYNAMIC_POPUP_MENU ) );
VERIFY( m_wndToolBar.SetButtonMenu( 
    nBtnIdx, _line_menu.Detach() ) );
CExtBarButton * pTBB = 
   m_wndToolBar.GetButton(nBtnIdx);
ASSERT_VALID( pTBB );
pTBB->SetSeparatedDropDown();

LRESULT CMainFrame::OnExtMenuPrepare(WPARAM wParam, LPARAM lParam)
{
   CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =
      reinterpret_cast<
         CExtPopupMenuWnd::MsgPrepareMenuData_t *
       >( wParam );
   ASSERT( pData != NULL );
   CExtPopupMenuWnd * pPopup = pData->m_pPopup;
   ASSERT( pPopup != NULL );
   
   INT nItemPos = pPopup->ItemFindPosForCmdID( 
      ID_TEMP 
    );

   if( nItemPos >= 0 )
   {
      pPopup->ItemRemove( nItemPos );
      pPopup->ItemInsert(
         nCmdID,
         nItemPos
      );
   }
}

Thanks, that works and will do what I want.

Is there a way to get the users menu selection via. a CMainFrame function instead of using ON_COMMAND(). The reason I want to do this is to be able to access the selected menu items MENUITEMDATA::LParamGet().

The menu LParam value is usually used to get some additional information about a menu item when a menu is constructed. When a command is handled, there is no way to find from where this command has been sent. It may be a menu item, a toolbar button or a piece of code that fired this command. Please tell us more about what you actually need so we can help you find an alternative way.

I thought there may have been a way to access the menus LParam when a menu item was selected but it doesn’t matter. I am processing the menu selection using the normal ON_COMMAND code and working backwards from there. So everything is ok.

Dear Support team,

how can I provide the CExtTabWnd class with custom tooltip text for each tab.

Thanks and best regards,

Axel

I noticed in both my application and your DrawCLI sample, that under certain conditions, a newly selected tab can stay highlighted after the mouse moves off the tab.

To reproduce:
- Run the DrawCLI sample and create 3 or 4 emtpy documents
- Switch between documents using the MDI tabs
- After clicking a new tab to activate, wait for 1 - 1.5 seconds before moving the mouse (estimate)
- Move mouse off the tab into the document area without rolling over an adjacent tab.
- Repeat prevous step until tab stays highlighted after moving off the tab

I can repeat this problem every 5-6 tries.

After creating a new document with two panes, the ASSERT(nIndex >= 0) fires in ExtSplitterWnd.cpp. Can you give me any tips on how to track this down? I can provide more details if needed.

From ExtSplitterWnd.cpp

    if( pOneNoteTabs != NULL )
    {
        bDrawDefault = false;
        LONG nIndex = pOneNoteTabs->ItemFindByHWND( pInnerFrame->m_hWnd );
        ASSERT( nIndex >= 0 );
        CExtTabOneNoteWnd::TAB_ITEM_INFO_ONENOTE * pTII =
            pOneNoteTabs->ItemGet( nIndex );
        COLORREF clrFill = pTII->GetColorBkDark();
        pDC->FillSolidRect( rcClient, clrFill );
    } // if( pOneNoteTabs != NULL )

My code:

BOOL CChildFrame::OnCreateClient( LPCREATESTRUCT /* lpcs */,
    CCreateContext* pContext)
{
    CRect rect;
    GetClientRect(&rect);

    CSize size = rect.Size();
    size.cy /= 2;

    if (!m_wndSplitter.CreateStatic(this, 2, 1, WS_CHILD|WS_VISIBLE, AFX_IDW_PANE_FIRST))
    {
        AfxMessageBox("Unable to create spliter window.", MB_ERROR);
        return FALSE;
    }

    if (!m_wndSplitter.CreateView(ID_GRID_PANE, 0, RUNTIME_CLASS(CGridView), size, pContext))
    {
        AfxMessageBox("Unable to create grid view.", MB_ERROR);
        return FALSE;
    }
    
    if (!m_wndSplitter.CreateView(ID_CHART_PANE, 0, RUNTIME_CLASS(CChartView), size, pContext))
    {
        AfxMessageBox("Unable to create graph view.", MB_ERROR);
        return FALSE;
    }

    m_wndSplitter.RecalcLayout();    

    return TRUE;
}

This problem presents itself after a bring up a modal dialog during CMyDocument::OnNewDocument. When I open an existing document and don’t bring up the dialog, then I do not get the assert.

I went on to find that the problem occurs if I just process a message loop inside of OnNewDocument() without bringing up a dialog.

We confirm that this is a bug. To fix it, open the ExtSplitterWnd.cpp file and replace the “if” statement with the problem ASSERT macros inside with the following code:

if( pOneNoteTabs != NULL )
{
   bDrawDefault = false;
   LONG nIndex = 
 pOneNoteTabs->ItemFindByHWND( pInnerFrame->m_hWnd );
   // ASSERT( nIndex >= 0 );
   if( nIndex >= 0 )
   {
      CExtTabOneNoteWnd::TAB_ITEM_INFO_ONENOTE * pTII =
         pOneNoteTabs->ItemGet( nIndex );
      COLORREF clrFill = pTII->GetColorBkDark();
      pDC->FillSolidRect( rcClient, clrFill );
   }
} // if( pOneNoteTabs != NULL )

Hello there,

Hi,

When my program runs for the first time the toolbars (i.e. CExtToolControlBar) are given default orders/positions (the following times the positions are saved and restored). The problem is that they all are positioned on the first row, which leads to that some toolbars are positioned outside the screen or at least major parts of some toolbars are positioned outside the screen.

This is very unfortunate as first time users may never find the features in the toolbars.

So, my question if how I could control the row the toolbar will end up on?

Thanks!

Yes, you are right. When your application runs for the first time, toolbars are docked in their default positions. But these positions are fully controlled by your code. So, if you want every toolbar to be fully displayed, that is to make all toolbar buttons initially visible, don’t dock too many toolbars in the same row. The following code demonstrates how it can be done for four toolbars:

// Dock m_wndToolBar1 in row 1
DockControlBar(&m_wndToolBar1); // Docked in row 1
RecalcLayout();
 
// Dock m_wndToolBar2 in row 1 next to m_wndToolBar1
CRect wrAlreadyDockedBar;
m_wndToolBar1.GetWindowRect( &wrAlreadyDockedBar );
wrAlreadyDockedBar.OffsetRect( 1, 0 );
DockControlBar( 
     &m_wndToolBar2,
     AFX_IDW_DOCKBAR_TOP,
     &wrAlreadyDockedBar
);
RecalcLayout();
 
// Dock m_wndToolBar1 in row 2
DockControlBar(&m_wndToolBar3);
 
// Dock m_wndToolBar1 in row 3
DockControlBar(&m_wndToolBar4);
RecalcLayout(); 

Hiding my CExtDynamicControlBar class by using close ("X") button works fine visually, except it’s visible state still == true.

Here’s my code to check visibility:
BOOL CustomIsVisible()
{
bool bIsVisibleState = false;
BarStateGet(&bIsVisibleState);
return (true == bIsVisibleState);
}

Am I doing something wrong?

Following code for bool CExtBarNcAreaButtonClose::OnNcAreaClicked(), it does this:
{
...
pFrame->ShowControlBar( m_pBar, FALSE, FALSE );
...

}


Should I override, and do this instead?

CExtDynamicBarNcAreaButtonClose::OnNcAreaClicked()
{
if( m_rc.PtInRect(point) )
{
BarStateSet( BarStateGet(), false );
}     
}

Yes, we confirm that this is a bug. The CExtDynamicControlBar class uses instances of the following classes for its caption buttons: CExtDynamicBarNcAreaButtonAutoHide, CExtDynamicBarNcAreaButtonMenu and CExtDynamicBarNcAreaButtonClose. The bug can be fixed by modifying the CExtDynamicBarNcAreaButtonClose::OnNcAreaClicked() method in this way:

bool CExtDynamicBarNcAreaButtonClose::OnNcAreaClicked(
   CPoint point
)
{
 ASSERT_VALID( this );
 if( !m_rc.PtInRect(point) )
  return false; // continue asking nc-buttons
 m_bHover = m_bPushed = false;
CExtDynamicControlBar * pBar =
  DYNAMIC_DOWNCAST(
   CExtDynamicControlBar,
   GetBar()
   );
 if( pBar == NULL )
  return CExtBarNcAreaButtonClose::OnNcAreaClicked( point );
 pBar->BarStateSet( pBar->BarStateGet(), false );
 return true;
}

Hello there,

I have some troubles on displaying the MRU menu text. My application uses an overwritten CRecentFileList in CWinApp. Command routing works fine, however, I cannot update the popup menu text of the last used documents the way CRecentFileList::UpdateMenu() does.

When I call MyRecentFileList->UpdateMenu(), the pCmdUI->m_pMenu is NULL and thus the function terminates.

I’ve checked the forum on similar issues (for instance, "MRU menu not updated correctly" by Andrey Del Pozo, April 17, 2004 or "Changing frame’s main menu" by Mirco Alexis, Feb. 11, 2004) and understood that Prof-UIS replaces the standard MFC menus, but this did not really help.

So, could you please provide a simple example on how to use the MRU menu in the way CRecentFileList::UpdateMenu() does?

Thanks,
Thomas

Dear Tomas,

The Prof-UIS pop-up menus are really not based on standard Windows menus so you should not use the CRecentFileList::UpdateMenu() method at all. Our pop-up menu uses the CRecentFileList::GetDisplayName() non virtual method for accessing all MRU file items. So, if you simply fill the CRecentFileList::m_arrNames array, then the Prof-UIS menu will automatically display it.

If this is not what you need, please let us know and we will find an appropriate solution for you.

Dear Alex,

Thanks for your prompt help, I fixed it. Actually it was my fault, since I used the wrong command IDs for the MRU list... :-(

However, I am not very happy about the way you access CWinApp::m_pRecentFileList in CExtPopupMenuWnd using your little "dirty hack" of InternalFriendlyWinApp, even though I fully understand why you do it this way.

The reason is because I would like to implement 2 different MRU list in my File menu (for instance, the way VS 2003 does for "Last used Files" and "Last used Projects"), for which I did not initialize CWinApp::m_pRecentFileList rather than using my own private version of this class, which then has caused the troubles I’ve had.

Anyway, after studying CExtPopupMenuWnd::_BuildItems() I have no clue how to implement 2 different MRU lists. My first thought was to re-assign CWinApp::m_pRecentFileList by my private pointers, which works fine as long as I use only one MRU list. However, since _BuildItems() is called recursively and because it builds up the MRU command list always starting with ID_FILE_MRU_FIRST, I am afraid it won’t work this way.

Any suggestions is highly appreciated.

Thanks and best regards,
Thomas

To implement multiple MRU lists in Prof-UIS pop-up menus, you need to follow an absolutely different approach. Each MRU list can be represented as a menu item with a unique command identifier in the menu resource of your application. The main frame window should handle the CExtPopupMenuWnd::g_nMsgPrepareMenu registered windows message and replace all the initial MRU command items with real MRU commands. This message is sent for each menu tree every time immediately before is appears on the screen. So, your function should be recursive. Here is the source code for the message handler:

 
    // declaration in the class scope
    afx_msg LRESULT OnExtMenuPrepare(
        WPARAM wParam, LPARAM lParam );
    //  message map’s entry
    ON_REGISTERED_MESSAGE(
        CExtPopupMenuWnd::g_nMsgPrepareMenu,
        OnExtMenuPrepare
        )
    // implementation
    LRESULT CMainFrame::OnExtMenuPrepare(
        WPARAM wParam, LPARAM lParam )
    {
        lParam;
        CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =
            reinterpret_cast
            < CExtPopupMenuWnd::MsgPrepareMenuData_t * >
            ( wParam );
        ASSERT( pData != NULL );
        CExtPopupMenuWnd * pPopup = pData->m_pPopup;
        ASSERT( pPopup != NULL );
        pData->m_bMenuChanged = 
            My_Walk_Menu_Tree_Recursive( pPopup );
        return TRUE; 
    }

 
    bool CMainFrame::My_Walk_Menu_Tree_Recursive(
        CExtPopupMenuWnd * pPopup
        )
    {
        ASSERT_VALID( pPopup );
        bool bRetVal = false;
        int nItemCount = pPopup->ItemGetCount();
        for( int nItemIndex = 0; nItemIndex < nItemCount; )
        {
            CExtPopupMenuWnd::MENUITEMDATA & _mii =
               pPopup->ItemGetInfo( nItemIndex );
            if( _mii.IsSeparator() )
            {
                nItemIndex ++;
                continue;
            }
            if( _mii.IsPopup() )
            {
                bRetVal ||= 
                    My_Walk_Menu_Tree_Recursive(
                        _mii.GetPopup()
                        );
                nItemIndex ++;
                continue;
            }
            switch( _mii.GetCmdID() )
            {
            case ID_MY_FIRST_MRU_MARKER:
                bRetVal = true; // menu will be modified
                // remove marker item
                VERIFY( pPopup->ItemRemove( nItemIndex ) );
                nItemCount --;
                // insert 3 real MRU commands without
                // any reference to the command manager
                VERIFY(
                    pPopup->ItemInsertCommand(
                        ID_MY_FIRST_MRU_FILE1,
                        nItemIndex ++,
                        _T("Solution file 1"))
                        )
                    );
                nItemCount ++;
                VERIFY(
                    pPopup->ItemInsertCommand(
                        ID_MY_FIRST_MRU_FILE1,
                        nItemIndex ++,
                        _T("Solution file 3"))
                        )
                    );
                nItemCount ++;
                VERIFY(
                    pPopup->ItemInsertCommand(
                        ID_MY_FIRST_MRU_FILE3,
                        nItemIndex ++,
                        _T("Solution file 3"))
                        )
                    );
                nItemCount ++;
            break;
 
            . . .
 
            default:
                nItemIndex ++;
            break;
            }
        }
        return false;
    }  

Hi,

there is different behavior of the menubar if it is docked or not.

Take your MDIDOCVIEW sample an uncomment in OnCreate()

m_wndMenuBar.EnableDocking( CBRS_ALIGN_ANY );

and

DockControlBar( &m_wndMenuBar );

Now click on the "Window" popup menu (so that the popdown menu is over the view)
move the mouse to the "Help" popup menu

--> the OnDraw in the view is called
(who is calling UpdateWindow??)

When the menubar is enabled for docking there is no OnDraw call.

Is this your intention??? How can I prevent the update call????

Thanks for your help

PS: I’m using Prof-UIS v2.27