Missing Button Click Message
-
The objective is to create a class that contains the methods to create and gather messages from a series of message dialogs by means of a series of buttons on a dialog created with the resource editor. The app is being written with VS 2010 and the classes, events etc. utilizing the supplied Wizards. This is an SDI app with p_MFCls-> pointing to the MainFrameEx* object and p->MsgCls being the child of p_MFCls-> and a CWnd* object. p_Dlg-> is a pointer to the actual dialog box and is a CDialog* object parented by the p_MsgCls object. FWIW: Windows 8.1 I have the following code (partial): In p_MFCls: //.h
CJBK_Msg* p_MsgCls;
//.cpp
p_MsgCls = new CJBK_Msg;
ASSERT(p_MsgCls->Create(NULL, NULL, 0, CRect(0, 0, 0, 0), this, IDCls_Msg));In p_MsgCls, when the appropriate message is received, we have:
//.h
CDialog* p_DlgBox;//.cpp
p_DlgBox = new CDialog;
ASSERT(p_DlgBox->Create(p_strMsgBox->nDlgBoxResID, this));For the button(s), I used the Event Handler Wizard but whether I tell it to send the event to p_MFCls or p_MsgCls, it never gets there when I click the button control. Can anyone spot something that I have missed? Thanks and Happy Holidays to all, Barry
-
The objective is to create a class that contains the methods to create and gather messages from a series of message dialogs by means of a series of buttons on a dialog created with the resource editor. The app is being written with VS 2010 and the classes, events etc. utilizing the supplied Wizards. This is an SDI app with p_MFCls-> pointing to the MainFrameEx* object and p->MsgCls being the child of p_MFCls-> and a CWnd* object. p_Dlg-> is a pointer to the actual dialog box and is a CDialog* object parented by the p_MsgCls object. FWIW: Windows 8.1 I have the following code (partial): In p_MFCls: //.h
CJBK_Msg* p_MsgCls;
//.cpp
p_MsgCls = new CJBK_Msg;
ASSERT(p_MsgCls->Create(NULL, NULL, 0, CRect(0, 0, 0, 0), this, IDCls_Msg));In p_MsgCls, when the appropriate message is received, we have:
//.h
CDialog* p_DlgBox;//.cpp
p_DlgBox = new CDialog;
ASSERT(p_DlgBox->Create(p_strMsgBox->nDlgBoxResID, this));For the button(s), I used the Event Handler Wizard but whether I tell it to send the event to p_MFCls or p_MsgCls, it never gets there when I click the button control. Can anyone spot something that I have missed? Thanks and Happy Holidays to all, Barry
-
The objective is to create a class that contains the methods to create and gather messages from a series of message dialogs by means of a series of buttons on a dialog created with the resource editor. The app is being written with VS 2010 and the classes, events etc. utilizing the supplied Wizards. This is an SDI app with p_MFCls-> pointing to the MainFrameEx* object and p->MsgCls being the child of p_MFCls-> and a CWnd* object. p_Dlg-> is a pointer to the actual dialog box and is a CDialog* object parented by the p_MsgCls object. FWIW: Windows 8.1 I have the following code (partial): In p_MFCls: //.h
CJBK_Msg* p_MsgCls;
//.cpp
p_MsgCls = new CJBK_Msg;
ASSERT(p_MsgCls->Create(NULL, NULL, 0, CRect(0, 0, 0, 0), this, IDCls_Msg));In p_MsgCls, when the appropriate message is received, we have:
//.h
CDialog* p_DlgBox;//.cpp
p_DlgBox = new CDialog;
ASSERT(p_DlgBox->Create(p_strMsgBox->nDlgBoxResID, this));For the button(s), I used the Event Handler Wizard but whether I tell it to send the event to p_MFCls or p_MsgCls, it never gets there when I click the button control. Can anyone spot something that I have missed? Thanks and Happy Holidays to all, Barry
You have wrapped the Create() functions in ASSERT() macros, which at least in Visual Studio 6.0 means they are executed only in debug mode. Assuming this behavior has not changed in VS 2010, you should use VERIFY() instead.
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
BarryPearlman wrote:
Can anyone spot something that I have missed?
Where is the actual event handling code? What you have shown above does not tell us anything about where these events are supposed to be captured.
Veni, vidi, abiit domum
Sorry about that! Ideally the button click event should be handled first in p_MsgCls since p_MsgCls-> is intended to handle all of the messages for the entire application. Second choice is CMainFrameEx. Using the Event Handler Wizard for p_MsgCls I get: //.h DECLARE_MESSAGE_MAP() public: afx_msg void OnBnClicked_MB_Btn2(); //.cpp
BEGIN_MESSAGE_MAP(CJBK_Msg, CWnd)
..........................ON_BN_CLICKED(ID_MB_Btn_2, &CJBK_Msg::OnBnClicked_MB_Btn2)
END_MESSAGE_MAP()void CJBK_Msg::OnBnClicked_MB_Btn2()
{
// TODO: Add your control notification handler code here
}I am working under the assumption that if the Event Handler Wizard (in general) presents me with a choice, it is a valid one and will work. Thanks, Barry
-
Sorry about that! Ideally the button click event should be handled first in p_MsgCls since p_MsgCls-> is intended to handle all of the messages for the entire application. Second choice is CMainFrameEx. Using the Event Handler Wizard for p_MsgCls I get: //.h DECLARE_MESSAGE_MAP() public: afx_msg void OnBnClicked_MB_Btn2(); //.cpp
BEGIN_MESSAGE_MAP(CJBK_Msg, CWnd)
..........................ON_BN_CLICKED(ID_MB_Btn_2, &CJBK_Msg::OnBnClicked_MB_Btn2)
END_MESSAGE_MAP()void CJBK_Msg::OnBnClicked_MB_Btn2()
{
// TODO: Add your control notification handler code here
}I am working under the assumption that if the Event Handler Wizard (in general) presents me with a choice, it is a valid one and will work. Thanks, Barry
BarryPearlman wrote:
I am working under the assumption
Never do that, check everything. However good the wizards may be they are not infallible. You can easily check that things are plugged together correctly by setting a few breakpoints in your code and running some controlled tests.
Veni, vidi, abiit domum
-
You have wrapped the Create() functions in ASSERT() macros, which at least in Visual Studio 6.0 means they are executed only in debug mode. Assuming this behavior has not changed in VS 2010, you should use VERIFY() instead.
The good thing about pessimism is, that you are always either right or pleasently surprised.
This post dealt with missing events, not a request for the difference between ASSERT() and VERIFY()! Frankly, I am hard pressed to find a decent explanation of the fine nuances between them, except their use during runtime and debug. It is my own personal philosophy that the end user should never see the arcane messages these macros produce. An error at a hex address means absolutely nothing to a user except that there is an error and that the developer has failed to take something into account. Perhaps a philosophical dissertation/lecture is in order here??
-
BarryPearlman wrote:
I am working under the assumption
Never do that, check everything. However good the wizards may be they are not infallible. You can easily check that things are plugged together correctly by setting a few breakpoints in your code and running some controlled tests.
Veni, vidi, abiit domum
I always do. That is how I found out that the code that the Event Wizard Handler was writing code that wasn't working in the first place. The question still remains why can't I get the event to fire in p_MSCls->? Thanks, Barry
-
I always do. That is how I found out that the code that the Event Wizard Handler was writing code that wasn't working in the first place. The question still remains why can't I get the event to fire in p_MSCls->? Thanks, Barry
-
Does the control that raises the event belong to this class, and are the message macros pointing to the right places? From the little pieces of code you have shown us it is not easy to understand how your project fits together.
Veni, vidi, abiit domum
You may be on the right class concerning who belongs to which class and hence the missing events. I will get back to this project later on in the week and thanks to you have some new avenues to explore. Thanks & Happy Holidays, Barry
-
This post dealt with missing events, not a request for the difference between ASSERT() and VERIFY()! Frankly, I am hard pressed to find a decent explanation of the fine nuances between them, except their use during runtime and debug. It is my own personal philosophy that the end user should never see the arcane messages these macros produce. An error at a hex address means absolutely nothing to a user except that there is an error and that the developer has failed to take something into account. Perhaps a philosophical dissertation/lecture is in order here??
This wasn't meant as a philosophical discussion. If you enclose an important function call, e.g. the creation of a dialog in an ASSERT(), the dialog will not be created in Release mode and therefore can't receive any messages. If you use VERIFY(), the dialog will be created in Release mode as well. However, the "arcance message" as you call it, will only be displayed in Debug mode.
The good thing about pessimism is, that you are always either right or pleasently surprised.