|
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()
{
}
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
|
|
|
|
|
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
|
|
|
|
|
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??
|
|
|
|
|
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.
|
|
|
|
|
I'm doing project on morse code translator in Cpp Im unable to write it?? plz help ....
|
|
|
|
|
Help with what? Please don't expect people here to do your work for you.
Veni, vidi, abiit domum
|
|
|
|
|
Dhananjay RajeNimbalkar wrote: plz help ....
Steps:
1. Learn the basics of C++.
2. Presumably you are going to do this from the command line so learn how to accept input and write output to the console in C++.
3. Learn how to parse a string (input)
4. Learn how arrays work.
5. Find source for a morse code map.
6. Put all of the above together to make your application.
|
|
|
|
|
Read and heed here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I did one of those many years ago. Since everyone's morse-code sending speed is a little different, you have to take this into account.
For a morse-code message you have pulses of different lengths. Sort the pulses by duration. Then look for the biggest gap between durations: This is the threshold between a "dot" and a "dash".
Now you can translate the pulses into dots and dashes, and the rest is just programming technique.
|
|
|
|
|
Hello everybody,
I am in project with win32.
I am using OPENFILENAME structure for selecting a file (GetOpenFileName()).
Problem is, it is possible to delete a file in browse dialog, which will create some issues.
is there any way to prevent deleting the files in browse dialog?
Regards,
A. Gopinath.
|
|
|
|
|
In order to have full control, you might implement the hook procedure.
Veni, vidi, vici.
|
|
|
|
|
This comes to mind.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I'm working with a MFC program based on DHTMLDialog in visual studio 2010, one problem is that sometimes IME is disabled in my program, which means I can only input English(no chinese) in it, another is that sometimes chinese can be input but the IME candidate window don't appear.( )
one cause of the first problem found is that flash disabled IME of the program via some C api.
How can I repair it? I try to use WINNLSEnableIME but seems to be no effective
Regards,
buaaxiao
modified 5-Dec-13 7:37am.
|
|
|
|
|
|
Hello,
I am learning MFC programming with the book "Programming Windows with MFC (2nd Edition)". I have some questions about the book example from chapter 9.
When I open a file or click new file, the function CSquaresView::OnDraw() is called. I checked the stack, the reason is that CView::OnPaint() calls this function. But I don't understand how CView::OnPaint() is called. Is the message WM_PAINT generated if CSingleDocTemplate::OpenDocumentFile() is called by the default setting? Is it possible to change the behavior?
Thanks,
Brian
|
|
|
|
|
My best guess is that the framework is drawing the view because a new document has just been loaded into it.
What is it you are trying to achieve?
Probably the only thing you can change is how the message is handled, not that the message is received.
Override the CView's OnWndMsg function to alter how any message is handled.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The CDocument class calls UpdateAllViews which in turn sends a WM_PAINT message to each view to redraw itself. In some cases you need to make that call in your code to ensure your views are current. You should check the documentation[^] for further details about its behaviour.
Veni, vidi, abiit domum
|
|
|
|
|
I set a break point in CDocument::UpdateAllViews(). It seems that this function is not called when opening or creating a file.
|
|
|
|
|
I found the reason. When either creating or opening a file, CSingleDocTemplate::OpenDocumentFile() is called. Then it calls InitialUpdateFrame(). Then InitialUpdateFrame() calls CView::OnUpdate() and CView::OnUpdate() calls Invalidate(TRUE).
|
|
|
|
|
I think you can find some documents from google about WM_PAINT, it is called by windows message
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
