When using a MFC ribbon based application, by default we get options to add keyboard short cuts for all our commands. So for example, I might use 'p' to bring up the print preview dialog. When I'm in a dialog, these commands are not active as you would expect, even if that dialog is not modal. However, if I click into an edit control on the ribbon these commands remain active, so for the example given I could not type 'p' into my edit control. A work-around is to add a modifier such as Ctrl + P or Shift + P but this makes the shortcut more awkward for my users. Is it possible to change the message filter either for the ribbon as a whole, or for individual ribbon controls, such that they ignore keyboard shortcuts the same way a dialog does?
Edit Some feedback here from related thread on MSDN
Related
Using MFC in Visual Studio 2012
I want to use a CMFCColorButton in a dialog in my application.
I added the CMFCColorButton button to my dialog in the resource editor (test it, works OK); click on the button and the underlying CMFCColorPopupMenu is display and stay displayed until manually dismissed (choosing a color or clicking somewhere else).
When I build my application and try the button in the dialog, it works differently, when I click the button, the underlying CMFCColorPopupMenu is displayed and immediately dismissed. If I want to select a color, I need to keep the mouse button down.
I tried in a different application (default MFC application) and I get the desired behavior (click and the CMFCColorPopupMenu stay visible).
I am not certain what could trigger the behavior difference.
I try toggling the CMFCColorButton::m_bAutoSetFocus value of the button and there is no change of behavior. ( I am not certain what is the purpose of this variable, but that is another subject)
Any ideas? hints/tips?
Thanks,
Max.
I have a legacy C++ MFC application with a complex GUI with Ribbons. I have a use case as follows : User clicks button A on a ribbon panel and does some work. After his work is done, before he can exercise the rest of the GUI controls, he absolutely must click button B on the same ribbon panel, and failing to click button B in this manner results in a crash if the user exercises some other controls.
Hence, in order to deal with this use case, I figured it would solve my problem if I could disable all of program's GUI controls in Button A's event handler except button B. Button B's event handler then enables the rest of the GUI controls. This way, I ensure that button B always gets pressed after button A.
Hence, my question to you is as follows : Is there a way to disable all GUI controls in one fell swoop, and then enable and disable controls individually?
I know how to enable or disable controls individually, but I have not yet come across an API that allows one to disable all controls.
This way, you get all IDs of the ribbon buttons:
CList<UINT, UINT>& lstItems;
CMFCRibbonBar *pRibbon = ((CMDIFrameWndEx*) AfxGetMainWnd())->GetRibbonBar();
pRibbon->GetItemIDsList(lstItems);
Put the three lines in your view's OnInitialUpdate() handler.
Then use the list to compare the IDs coming through your OnCmdMsg() handler to disable all the buttons (except button B).
I have a design like below:
So basically, I want to embed three dialogs in the application main dialog and switch between them, for each button click i.e., button 1 will show dialog one , button 2 will hide dialog 1 and show dialog 2 .. and so on.
Each dialog will be having a different design and functions.
I tried using CPropertySheet class to Add pages but its GUI is different. It has either option for navigating the dialogs using next / back button , or from a tab control.
None of which is as per my requirement.
So I want to know is it possible to have a design like this in MFC ? If yes how? Which Class/ control should I use.
Any help will be appreciated.
What you can do is use a normal CDialog class, add your buttons to it and also create a frame/rect as a placeholder for where your embedded dialogs are to appear. The following piece of code will create and position your embedded dialog.
CRect rect;
CWnd *pHost = GetDlgItem(ID_OF_YOUR_FRAME_RECT);
pHost->GetWindowRect(&rect);
ScreenToClient(&rect);
pDialog->Create(ID_OF_YOUR_DIALOG, this);
pDialog->MoveWindow(&rect);
pDialog->ShowWindow(SW_SHOW);
On button clicks, you hide the previously shown dialog (SW_HIDE) and show your selected dialog(SW_SHOW) with ShowWindow(...).
If you create your embedded dialogs with IDD_FORMVIEW style in the add resource editor it'll have the proper styles for embedding.
Another option is probably to use an embedded PropertySheet and hide the tab row and programatically change the tabs on the button clicks. I just find it to be too much fuzz with borders, positioning, validation and such for my liking.
If you have the MFC Feature Pack, that first came with VS2008 SP1 and is in all later versions, you might like to consider CMFCPropertySheet. There are a number of examples on the linked page, that are very similar to your design.
For example, this:
What worked for me just using dialog based application is SetParent() method. Dont know why nobody mentioned it. It seems to work fine.
I am doing like below:
VERIFY(pDlg1.Create(PanelDlg::IDD, this));
VERIFY(pDlg2.Create(PanelDlg2::IDD, this));
VERIFY(pDlg3.Create(PanelDlg2::IDD, this));
::SetParent(pDlg1.GetSafeHwnd(), this->m_hWnd);
::SetParent(pDlg2.GetSafeHwnd(), this->m_hWnd);
::SetParent(pDlg3.GetSafeHwnd(), this->m_hWnd);
Now I can show or hide a child dialog at will (button clicks) as below:
pDlg1.ShowWindow(SW_SHOW);
pDlg2.ShowWindow(SW_HIDE);
pDlg3.ShowWindow(SW_HIDE);
I have a C++ MFC MDI application. I have a tool bar with some buttons on it. I need to add some check boxes to this toolbar and i need them to have custom bitmaps just as my buttons do. Thanks
EDIT:
By bitmpas i refer to the pixel images that can be created using the tool bar editor in visual stuidos 2008. I would like a picture (of my creation) instead of the usual tick box.
You don't use checkboxes on toolbars.
You should rather use regular buttons in Check mode. That means that the button stays pressed when user releases it. Clicking it a second time releases the button. This is the same behaviour as a checkbox.
You can either set a toolbar button as checkable by code:
m_ToolBar.SetButtonStyle(nButtonId, TBBS_CHECKBOX);
Or by enabling the corresponding property in the resource editor.
If you want to modify the image displayed when the button is pressed, in your ON_UPDATE_COMMAND_UI handler, use m_ToolBar.GetButtonInfo() to check if the image matches the state. If not, change it using m_ToolBar.SetButtonInfo() and specify the index of an extra image added to the image list of the toolbar.
The following is a link which might help you
http://www.ucancode.net/Visual_C_Control/Place-Combo-Edit-Box-Progress-Control-On-ToolBar-CToolBar-VC-Example.htm
I currently have some toolbar buttons with a small arrow on the side (TBSTYLE_EX_DRAWDDARROWS) that, when clicked, result in a popup context menu being displayed under the button. This is done by constructing a custom popup menu and calling TrackPopupMenu.
The client now wants to be able to select multiple options from the menu before it closes, so that multiple options can be be modified without the need to re-open the menu and wait for an intermediate redraw between each change.
For example:
User clicks dropdown button
Dropdown menu appears (modal, waits indefinitely for user action)
User clicks some item (e.g., toggle a checkmark)
Timer (e.g., 500ms) starts
If timer expires, the menu is closed and all selected actions are executed.
User clicks another item before the timer expires, go back to 4.
The best I can come up with is to redisplay the menu by calling TrackPopupMenu multiple times. This makes the menu "flicker" when you select an item, and will probably require me to start a thread in order to do the timeouts, which I would rather avoid.
Rather than a menu, put up a dialog box with the options on it. A dialog can easily do all that is required.
A menu that doesn't close when you click it will just seem wrong. A dialog that closes by itself will seem wrong too, but it's probably the least of two evils.
Edit: If there's anything I've learned with Microsoft, it's don't try to fight the default behavior. You're asking for trouble if you do.
If you're building your menu dynamically I can see how automatic sizing can be handy, but it's not hard to do in a dialog either - make the dialog really big and before it becomes visible, enumerate the children and take a union of all their rectangles, then resize to that. Checking the boundaries to make sure they're on-screen is just a few if statements with OffsetRect. Checkboxes are trivial; icons less so, but still not bad.
One additional enhancement that would be easy to add is to dismiss the dialog immediately on a double-click.
Following #Mark Ransom's answer, you should put up a dialog box. But you can make the dialog modeless and make it close itself when you click outside of it (i.e., the dialog loses focus). That way it could behave more like a menu.
Notice that normal menus never go away by themselves, you always have to click somewhere outside the menu (or one of its options) to make it disappear.