Professional UI Solutions
Site Map   /  Register
 
 

Forum

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 Tech Support » How to associate window menu hMenu to CExtMenuControlBar Collapse All
Subject Author Date
Chris Anderson Apr 19, 2007 - 2:31 PM

Hi,
We have a module which creates the window menu at run time using Windows SDK API’s. Now I have changed the Main window to use the prof-UI theme. After this, the menubar has got dis-appeared and found that they were overlapped on Window caption!. Is there a simple solution to overcome with this issue? Or Do I have to use CExtMenuControlBar()? if so How to associate the hMenu to this CExtMenuControlBar object?

Thanks

Technical Support Apr 29, 2007 - 9:49 AM

We haven’t still received the sample. It may have been filtered out somewhere. Would you send it to profuis at gmail.com?

Chris Anderson Apr 27, 2007 - 4:36 PM

I have sent you the sample through e-mail provide the clear pitcure on the issue

Chris Anderson Apr 27, 2007 - 12:57 PM

I do not want the status. I need the menu item at the top level to be enabled without frame having the message map. So without adding any message handler is there a way to set the menu item to be always enabled?

Chris Anderson Apr 26, 2007 - 6:09 PM

I cannot add the MFC menu handler as the menu is populated at runtime using the SDK functions. Is there an alternate way to make sure that the "Test" menu item in the menubar is enabled?

Technical Support Apr 27, 2007 - 11:42 AM

Let us suppose your application knows exactly the menu structure. In this case it is not a problem to find any menu item by its index and nested location in the menu tree and check its disabled state. In the case of Prof-UIS, you have a pointer to the CExtPopupMenuWnd object representing one menu level and an index of the menu item in the menu level. So you can use the CExtPopupMenuWnd::ItemEnabledGet() method to check if menu item is enabled.



Chris Anderson Apr 25, 2007 - 4:35 PM

This approch cannot be used in our application. We provide the IDE tool which allows user to create the menu at runtime and associate the action. So we have our own mapping and use Window API to create the menus. There would be lots of effort to migrate and test these code to fit the Prof-UI architecture for Menubar.

In the mean time I have figured a way to make the code to work by handling the message CExtPopupMenuWnd::g_nMsgPrepareOneMenuLevel and with the follwoing code:

...
    CExtPopupMenuWnd * pPopup = pData->m_pPopup;
    ASSERT( pPopup != NULL );

    HMENU hMenuPopup = pPopup->ExportToMenu(TRUE);

// Follwoing code would go through each menu items to enable / disable using the windows API
// This function call was earlier placed in WM_INITPOPUPMENU
    FesMenuInitPopup(GetMenuOwner(), hMenuPopup, 0, FALSE);

    CMenu menuPopup;
    menuPopup.Attach(hMenuPopup);
    pPopup->UpdateFromMenu(m_hWnd, &menuPopup, FALSE);

The above stuff works fine for the poupup menu in menu bar. Suppose if a menuitem (command) exist in menu bar then I cannot enable/disable. E.g., The menu bar as "File" a poup menu, "Edit" a poup menu, and "Test" a command menu item. Now The "Test" menu item is always disabled!. How could I atleast force this menu item "Test" to be enabled?

Thanks


Technical Support Apr 26, 2007 - 1:28 PM

The menu bar (CExtMenuControlBar) is an extended version of the toolbar (CExtToolControlBar). So the top menu is not based on popup menus (CExtPopupMenuWnd) but rather on toolbar button objects (CExtBarButton). The buttons are built in CExtMenuControlBar::_UpdateMenuBar(), which is an internal virtual method. The menu bar has a simple implementation. It keeps HMENU of the window menu and resets the real window menu to NULL. The top level menu items contain HMENU handles of top level HMENU kept in the menu bar. Yes, these menu bar buttons are always enabled and never updated using the MFC’s command updating mechanism. We do not think this is a real problem if each command is updated correctly according to each state in your application.

Chris Anderson Apr 23, 2007 - 6:01 PM

Thanks.

The menu bar was not displayed with CWnd. After changing the frame to CFrameWnd, the menu bar was displayed. In our code we trap WM_INITMENUPOPUP and then enable or displae the menu items. After using CExtMenuControlBar, the window was not getting the message. Please suggest on how to trap this message for enabling / disabling of the menu items.

Technical Support Apr 25, 2007 - 3:42 AM

There is an article Constructing Menus Dynamically at Run Time that answers your question. Please note that in Prof-UIS, the state of all menu items and toolbar buttons is controlled by the MFC’s command updating mechanism. So to enable/disable a menu item, you need to add the command updating method for the command associated with this menu item to your CMainFrame class. You can generate this method using Visual Studio.

// method declaration:
 afx_msg void OnUpdateMyCmd(CCmdUI* pCmdUI);
 
// message map entry
 ON_UPDATE_COMMAND_UI(ID_MY_CMD, OnUpdateMyCmd)
 
// method body
 void CMainFrame::OnUpdateMyCmd(CCmdUI* pCmdUI) 
{
    pCmdUI->Enable( FALSE );
}

Technical Support Apr 20, 2007 - 8:16 AM

If you create the standard menu line only once at startup, then you can simply subclass its parent window with CFrameWnd and create the menu bar in it. If you create the menu line more than once, you should use the CMenu object returned by the CExtMenuControlBar::GetMenu() method and invoke the CExtMenuControlBar::UpdateMenuBar() method each time the menu is modified. Please note that if you want to assign a menu handle to the window, you should not use the ::SetMenu() Win32 API at all. Just assign some menu initially and then use that returned by the menu bar.