I've created a simple Dialog box with a few controls (edit, text, etc) and saved
it to the resource folder in GME/GME.rc/Dialog
I added an auto-gen'd event handler which created a new class (Class.cpp
for the purposes of this example) Note: the Class::Class(CWnd *pParent) :
CDialogEx(Class::IDD, pParent) constructor is empty, I'm not sure if that's
relevant but I don't think it is..
There's a MESSAGE_MAP COMMAND(menu_item_id, &class::member_function())
invocation within the Class.cpp was auto-generated. It's wrapped in the
standard BEGIN_MESSAGE_MAP macro stuff.
However: when the menu item is clicked, the item remains gray. The
properties for "enabled=true" and "gray=false" are both properly
configured. So, I assume this is error is due to the message handler isnt
registered.
Any help would be appreciated.
Without code, it's pretty darn hard to help. Are you sure you put the message handler for the menu id in either a CView, CFrame, CDocument, or CWinApp derived class? If you put the menu handler in your dialog class, it's not going to do you much good.
Dialogs do not contain the code to run through the list of ON_UPDATE_COMMAND_UI handlers that MFC uses to enable menu items. Ordinarily this is handled by CFrameWnd for example. Try calling UpdateDialogControls in your OnInitDialog function.
I see that your code is also missing the ON_UPDATE_COMMAND_UI macro for the menu item, even though the handler it would reference was created for you.
You add menu item handlers to the window that has the menu, which is usually the CMainFrame. Copy the message map and handler to the CMainFrame and see if that helps. I'm not sure what you're trying to do here - I assume you want to display 'Class' (maybe better to edit your post to call this 'ExampleDialog' or something...) when the menu item is clicked, right? Or did you somehow add a menu to your CDialogEx-derived class? If the last, I guess this is what Mark is referring to - 'how are you displaying the menu'? How are you manually adding a menu to your dialog?
Related
I have a CDialogEx Class called Properties in which I handle the ON_COMMAND message. Now, ON_COMMAND should get called when I click the menu item ID_EDIT_PROPERTIES (as a submenu from main menu). The event handler wizard wrote that code for me, but when I start the Application the menu item remains grayed out. I've tried to manually activate it by calling EnableMenuItem when ON_UPDATE_COMMAND_UI happens, but to no avail.
Any help would be greatly appreciated.
You just need to understand how menu items enabling/disabling is handled:
If there is neither ON_COMMAND nor ON_UPDATE_COMMAND_UI handler the item is disabled.
If there exists no ON_UPDATE_COMMAND_UI handler but there is an ON_COMMAND one in the currently active document or view (or even the "mainframe"), the item is enabled.
If there exists a ON_UPDATE_COMMAND_UI handler, en-/disabling the item is determined by the handler (pCmdUI->Enable(bEnableState)).
Also keep in mind that:
You may not call EnableMenuItem() yourself, instead call pCmdUI->Enable(bEnableState) in an ON_UPDATE_COMMAND_UI handler. This affects not only the menu item, but any other "command"-type item (with the same ID), eg main menu, context menu, toolbar or rebar button.
Where to put the handler, is a matter of application design and depends on the data you are processing or representing. It can be put in the mainframe class (if it depends on some "global" data or setting), in the document class (if it depends on or changes some data or setting in the document - possibly affecting all views), or in the view class(-es) (depending on or affecting the current view only).
In your case, if I understand correctly, the item is disabled because the handler is in the CDialogEx-derived class, but no instance of this class has been created yet, ie there exists no ON_COMMAND handler for your ID_EDIT_PROPERTIES command.
Per m_bAutoMenuEnable, When this data member is enabled (which is the default), menu items that do not have ON_UPDATE_COMMAND_UI or ON_COMMAND handlers will be automatically disabled when the user pulls down a menu.
I admit that I don't know ii it is different for CDialogEx, But for CDialog I found that the UPDATE_COMMAND_UI didn't ever work unless I handled the WM_KICKIDLE event.
In your OnKickIdle event handler make a call to:
CWnd::UpdateDialogControls
There is a short tutorial on it here.
Forgive me if CDialogEx supercedes this information and I will remove the answer.
I am having a proglem with the MFC application and the DialogBox. I am quiet sure I've done everything well with this tutorial: https://msdn.microsoft.com/en-us/library/6wb9s9ah.aspx
but still it doesn't work...
1. I've created new project with simple menu commands.
2. I've created new menu item (+ID) and new resource DialogBox (+ID).
3. Then I've added a new class named CParameters with the Class Wizard. For the BaseClass I've typed in CDialog.
4. I've created new handler on the menu item and added the code
CParameters dlg;
dlg.DoModal();
I think this is it, and this should work... But it doesnt... What is missing??
Here is my project, you can access it freely:
https://www.dropbox.com/sh/e6ajoxqk76hkuvn/AACRMY8bgcuyXguFwP240QB9a?dl=0
Additionally I want to insert TextEditors and to change parameters in my program from the dialog box.
A scan of your source code reveals that you are trying to handle the menu item event within the class that is going to display the dialog.
void CParameters::OnParam()
{
// TODO: Add your command handler code here
CParameters dlg;
dlg.DoModal();
}
I don't see anywhere else that you actually instantiate the dialog class (I may have missed it). What you are trying is incorrect. You cannot handle the menu item event within the same class that displays the dialog because that class (CParameters) has not been instantiated, so, it cannot respond to the menu event. Typically, the menu event would be handled in the mainframe class.
If you are doing this by adding a new menu item from a simple SDI application, then trying adding that part of code in
CMainFrame::OnEdit
OnEdit method used here is obtained from the Event Handler for the new menu item and Message type being COMMAND.
I want to build a MFC application, with one main dialog, and all the other dialogs are child of this main dialog (and embedded in it).
Now, i was able to embed the first child in the main dialog, but i want to pass to the next dialog (note that the order of opened dialogs is random), so i need to hide the first dialog and show another. To know which dialog is shown at the moment and hide it, i've tried using a CDialog variable to store the current opened dialog, but i get a CObject::operator =' : cannot access private member declared in class 'CObject' error.
Is there another way to do this "hide and show dialogs" game?
EDIT: Could i store some ID of the dialogs and use it to acomplish this task?
So i managed to accomplish this task using classes IDDs.
First, i store the last opened dialog's IDD
m_dlgStartPage.Create(CStartPageDlg::IDD, this);
m_openedWin.nDialogIDD = m_dlgStartPage.IDD;
m_dlgStartPage.ShowWindow(SW_SHOW);
Then, when a new dialog needs to be shown, i send a message to my main dialog (nIDD is the IDD of pending dialog to show):
AfxGetApp()->m_pMainWnd->SendMessage(WM_COMMAND_CHANGE_WINDOW, nIDD, 0);
And last, in my main dialog, i parse all the child dialogs and check if m_openedWin.nDialogIDD matches with each dialog's IDD, so i can hide it. After this, i parse once again all the chid dialogs and use the nIDD from the sent message to show the correct one.
I don't really like this approach, because of all the parsing and sent messages to the main dialog's class, so if anyone has a better idea or method, please post it.
I have a MFC app written in Visual Studio 6 which I am adding some new functionality to. What I want to be able to do is display a context menu when the user right clicks on the header column on the list control within a property page. The CListCtrl class was added view the Class Wizard.
Via the ClassWizard for the property page, I have added a handler for the right click on the listctrl. This does get called and I added the following code to work out if the rclick was over the header section and if so which header item. Like this
POINT Point;
GetCursorPos (&Point);
ScreenToClient(&Point);
HDHITTESTINFO HitTest;
//Offset of right scrolling
HitTest.pt.x = Point.x+ m_ctrlRecordList.GetScrollPos(SB_HORZ); //Offset of right scrolling
HitTest.pt.y = Point.y;
//Send the Hit Test Message
m_ctrlRecordList.GetHeaderCtrl()->SendMessage(HDM_HITTEST,0,(LPARAM)&HitTest);
// Check hit test result.
*pResult = 0;
However, the hit test always returns -1.
I tried just on left click instead by handling the HDN_ItemClick message of the header control in the property page. This is all done in the ClassWizard so I expected to be able to handle this notification here. However, from what I have researched so far, there may be a bug in MFC where the ClassWizard puts this code into your code for you but this notification will never get as far as the parent of your list control. Is this the case?
What would be the best way to do this? I would prefer on right click but left click would do if necessary.
You cannot do it trying to handle message from a list’s header in a dialog, nor can you do it in the CListCtrl derived class.
MFC is using message reflection for certain controls and only for certain messages/notification codes.
Most likely you are passing coordinates of the mouse click on the list control, hence hit test fails.
Try this:
Add class derived from CHeaderCtrl. Declare member variable of the derived class in a dialog.
I assume you have already subclassed (have variable inserted by the wizard) list control.
In OnInitDialog write the following:
// m_List is the dialog’s member of the subclassed list control,
// m_header is a member variable of your new header class:
// insert this code after list control is already
// initialized and all columns are added.
CHeaderCtrl* pHeaeder = m_List.GetHeaderCtrl();
m_Header.SubclassWindow(pHeaeder->m_hWnd);
Insert handler for WM_CONTEXTMENU or WM_LBUTTONUP in the derived class and popup menu. You will receive CPoint type for click position.
I have managed to sort this out and thought I would add the answer in case anyone else stumbles upon this with the same problem. The code I posted originally is fine but it needs to go in the OnNotify handler of a class derived from CListCtrl. The ClassWizard allows you to add a reflect handler to the parent of the list control but the message never gets that far.
I have a first dialog with a simple button on it and while clicking the button, a second dialog is created using CDialog::Create(IDD,this). I would like the parent to be notified when the second dialog is destroyed but without adding any code to the second dialog i.e., without adding a m_pParent->Notify() line in OnDestroy method.
I have tried OnParentNotify, PreTranslateMessage, SubclassWindow in the parent dialog with no success. I have not used the WS_CHILD style for the second dialog. Any idea?
To complete: in fact, I have a ComboBox derived class (but the issue is the same with buttons) and I'm displaying a modeless Dialog instead of displaying the listbox. But I would like the control to be as generic as possible so that any modeless dialog could be used. That's why I do not want to add a specific notification in the second dialog. If I'm obliged, I will use this trick but I asked for a more generic solution. PreTranslateMessage only catches WM_PAINT, WM_NCMOUSELEAVE and WM_NCMOUSEMOVE.
Use a base class and have your parent refer to the modeless child by base class only. In the base PostNcDestroy have it post to the parent.
It doesn't make sense to have the parent do a bunch of filtering / spying on all messages. It does make sense to implement behavior in a base class that you want to have common to all the different future flavors you might have of the modeless child.
OnParentNotify() is not called since dialog2 is not a child of dialog1.
PreTranslateMessage() should help here (although I don't like this bullet). The trick is that a modeless dialog doesn't destroy itself when it's closed. If you want the dialog to die, it must call DestroyWindow() when it closes, such in an OnCancel() override.
Of course, the first thing that comes to mind is t wonder why you don't want to add custom notification in your modeless dialog code.
EDIT: Another method would consist in installing a message hook (for the current thread, Not the whole system!). This would help you catch all messages for all windows associated to the same thread as dialog1. See SetWindowsHookEx()
How about posting a main parent form event to the message queue?