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).
Related
I've got two little questions at Visual Studio MFC-GUI programming technique regarding the handling of a group of radio buttons in VS2015 CE.
I have a little dialog based application. This application draws some lines on my dialog with a specified pen.
Now I made a group of radio buttons to be able do use different colors for the pen. So I created a group box, placed the radio buttons into this group box, enabled the group property of the first radio button and checked the tab sequence so that all of the radio buttons are properly in sequence.
That's ok - testing the GUI I'm able to select just one of the radio button as planned, because I wouldn't be able to draw a line in to different colors at the same time. Now I added an handler for the BN_CLICKED Message of the first radio button object in the ClassWizard to add the selection of different colored pens.
Now comes the interesting part. This handler is executed only when i click the first radio button. The one with group property enabled. I thought it should be executed whenever I click any of the radio buttons in this group. The next thing I tried was to add an BN_CLICKED-Messagehandler to all of those radio buttons, but the ClassWizard does not shows the BN_CLICKED Message for the other radio buttons - only for the one with group proerty enabled.
After googling around I read a post that one would be able to add an BN_CLICKED-Messagehandler for an button by simply double clicking it in the Dialog. So I double clicked all of my radio buttons and added an invocation of the BN_CLICKED-Messagehandler of the first radio button. That's working as a workaround so that now my line is drawn in the different colors whenever I click on any of those radio buttons (black, blue, red , and so on).
I have two questions - is this behaviour intended? I suppose the reason why I'm only able to add a BN_CLICKED-Messagehandler in the ClassWizard for the first radio button is, that it would be invoked by any of the radio buttons in my group, wouldn't it?
Another question is, I would have preferred to write the handler once and be able to tell the class wizard to use this particular handler instead of creating a unique handler for each of the buttons. That's independent of this radio buttons. I tested this with a simple application which consists of an assembly of several buttons - which can have their own BN_CLICKED-Messagehandlers attached by the class wizard. When I didn't accept the automatically generated functionname from the wizard and enter the name of my own handlerfunction it simply states that it wouldn't be able to overwrite it. How can I select an existing handler for an object message in the class wizard or is that not possible and I have to do this manually in code for myself?
Hope there's an VS2015 MFC Guy out there be able to tell me ..
This is indeed by design. You could have wanted different behaviour for each button click - if you don;t simply associate all of the BN_CLICKED to the same message handler and delete the ones that were automatically generated.
You can also use ON_CONTROL_RANGE(BN_CLICKED, id1, id2, memberFxn ) - make sure your buttons are in the same range in your resource.h
Hope that helps!
I am coding a test application for a windows CE device. This is the first time I am programming for a handheld device. I use MFC VC++ on Visual Studio 2008. I have found that there are many restrictions in the controls and what I could do with them when running the program on a handy versus when I run a similar program on a desktop computer.
Now, the device I am currently deploying my test program to, does not have a touchscreen and has few extra keys other that the numberpad 0-9 keys. So, I have to do with a simple GUI that uses keydowns to call specific functions like add, edit, delete etc... It also forces me to use separate dialogs for each of these functions so as to avoid unnecessary mouse cursor usage.
This leads me to my current problem: The 'ADD' dialog of my test app adds some user data to a CListCtrl that is on the 'MAIN' dialog. The 'EDIT/DELETE' dialog is to allow the user to select the desired data from its own CListCtrl and press the "ENTER" key, which thereby deletes the selected data from the 'MAIN' dialog's CListCtrl. Thus, both the main dialog and the 'EDIT/DELETE' dialog have CListCtrl with the exact same data. So, instead of having to use 2 separate list controls and using loops to copy the data to and fro among them, is there a way in which i could use the exact same CListCtrl (one and only one instance of the CListCtrl exists), but display it on 2 separate dialogs? This would remove all the copying code, as well as halve the amount of data in memory.
I tried passing a pointer to the MAIN dialog's CListCtrl to the 'EDIT/DELETE' dialog in hopes that I could redraw the control there, but in vain. I could call the RedrawWindow, RedrawItems commands, but they seem to have no effect in the 'EDIT/DELETE' dialog (I think it is because the control itself is not present on the edit/delete dialog). Any other suggestions?
You could temporarily change the parent of the ListCtrl using CWnd::SetParent to the EDIT/DELETE dialog, and set the position with CWnd::SetWindowPos to where you want to have it. When the dialog gets closed, set the parent back to the MAIN dialog.
I need to extend an existing MFC app with a UI that will end up very cluttered unless I use a tab control. However, the nature of the UI is that there are some controls that are global, and only some that can be localised to a particular tab.
The standard use of tab controls (CPropertySheet + CPropertyPage) more or less expects there only to be CPropertyPage instances (tabs) visible on the CPropertySheet object, and nothing else. There is a Microsoft Example Project that shows a single additional window painted outside the area occupied by the tab control... but it's not immediately clear how it is created/drawn/handled, and it is only one single additional window that generates few events (I guess it is painted, so there must be a WM_PAINT event handler lurking somewhere).
Is it possible to lay out a bunch of controls with the MS Dialog Editor, including a tab control, and create the CPropertySheet using that template, hook up event handlers in a nice way, etc... or some equivalent way of getting the MFC framework to do as much of the creating, drawing and event handling as possible when it comes to a situation like this?
Yes it is possible to create dialog templates and use them in a CPropertyPage.
Each CPropertyPage behaves nearly like a dialog and handles all events for the controls on it.
Also there are features like OnApply that help you to manage the data exchange between the controls and your internal storage.
The central CPropertySheet only creates the dialog that get active. So OnInintDialog for a page is called the first time when the page gets active.
In the MFC since 2010 are more possibilities than a CPropertySheet. You can create tabbed views, that again may be CFormViews. I don't like CDialog based applications so I would prefer a tabbed view in a standard frame with toolbar and menus if appropriate for the application. So another method to unclutter your UI is to choose the MDI interface with tabbed documents... but multiple documents maybe isn't what you want.
Here is a sample of an SDI application with multiple tabbed views.
Also Coeproject shows some more samples here and with splitters and tabs here.
There are at least three solutions paths:
Try to squeeze the situation into the CPropertySheet + CPropertyPage framework which does not naturally allow for additional dialog controls on the CPropertySheet object, and so you will get no framework support this
Place a tab control on an ordinary dialog, and then use the TCN_SELCHANGE messages to fire code that manually hides & shows individual dialog controls subject to the tab control (again no framework support, but this time "within" the tab control instead of outside it)
Follow Mark Ransom's observation that if you can embed one kind of CWnd-based control on a CPropertySheet then you can probably embed any such object, including a CDialog-based object that has been developed in the MFC Dialog Editor
All of these approaches are going to encounter challenges, and it will depend on the specifics of the situation as to which is better. But first you should really consider whether there is a cleaner UI design which would lend itself to a simpler solution.
In my specific case, I saw no cleaner design alternatives, and found it easiest to take the second approach. It left me with some reasonably simple calls to ShowWindow() to show/hide the controls inside the tab control.
I have a document within MFC C++ application. I need to delete one the buttons from the particular CMFCToolbar within a code (not resources) completely, even preventing a user to restore the button via toolbar customization dialog. At this moment I use RemoveButton method of CMFCToolbar but it only makes the button invisible and it can be restored via toolbar customization dialog that is not an option for me at this time. I will be very glad if you suggest something that can help me there.
There are two internal lists in CMFCToolBar that are used to reset the Buttons upon customization.
They are named m_OrigButtons and m_OrigResetButtons.
You may need to derive your own class and delete the buttons with the specific IDs from there.
But better: Never to include such a button on the first time when the toolbar is created!
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.