Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ MFC MessageBox
Hello to everyone,
 
This thing is driving me crazy for the past days, so i would appreciate any insight.
 
Im writing an MFC dialogue application in VS2008.
 
In simple words im doing the following.
 
I have a function that is a member of the *dlg class (lets call it MyAppDlg::PostMessageToDB()).
 
I have created a timer and an MyAppDlg::onTimer() handler method that gets called whenever the timer ticks.
 
I have also created an MSMQ COM object and have registered its "Arrived" event with the MyAppDlg::newMessage() function. This function gets called when a new message arrives in the MSMQ queue.
 
Both these functions call the PostMessageToDB() function.
 
If theres an error (e.g. no connectivity with the DB) the PostMessageToDB() function pops an error message by calling the AfxMessageBox( errorMsg, MB_RETRYCANCEL |MB_ICONERROR| MB_SYSTEMMODAL); method.
 
This method is modal. The execution of the PostMessageToDB() function freezes and my application does not continue until the user hits the retry (or cancel) button.
 
So far so good.
 
BUT while waiting for a user response, if the timer ticks again or a new message arrives, my application gets woken up! The corresponding functions are called and it seems like a new "instance" of my program starts its execution flow. The result is to reach again at the same error and pop another error message.
 
How can this ever be possible?
Is anywhere there a hidden thread involved?
What will happen if i press the retry button while another "instance" of the above flow is on its way?
 
To what i know, the new event (timer tick or new message in the queue) shouldn't be dispatched before my application completes the processing of the previous message and returns. That's how the windows message loop works right?
 
I guess i miss the basics of the MFC architecture. If you know a link to a tutorial/article that can help me understand the above behavior i would be grateful!
Posted 31-Oct-11 5:32am
Edited 31-Oct-11 5:43am
RaisKazi33.1K
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

It seems likely that the message box calls are from new threads. This leaves your main thread responsive and thus able to process new messages. In such a scenario it's best to avoid using a message box, and a better idea may be to use a modeless dialog with a listbox that shows a running log of errors.
 
Alternatively, make sure you sync the threads and stop processing new messages until the user has dismissed the messagebox.
 
As to why or how this happens I'd guess that the MSMQ events are fired on new threads (from a thread pool).
  Permalink  
v2
Comments
dlavrantonis at 31-Oct-11 11:37am
   
thank you very much for your response. Stopping the processing of new messages until the user dismisses the message box is exactly what i want to do. Do you know how this can be done? I mean is there any straightforward way, or i will have to do it "manually"?
Albert Holguin at 1-Nov-11 10:38am
   
It's a bit odd that those are going through, but it is possible that you have more than one thread, in which case they would go right on through... You can use a mutex to block the message loop, or alternatively, stop the timer every time you go into the error state (which will probably be best option)
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

if your using SEH structured exception handling, it may have broken off to the message loop ( yes it can do that). That will only happen on windows mobile/ce to my knowledge but never tested it. Turn off SEH on the compiler and try it again.
 
Use spy++ to watch the messages.
 
Write your own model dialog by just writing your own message pump and the error will be obvious. It's not many lines of code. If you want to handle timer messages properly you'll end up writing it yourself as model dialogs and timers are not friends. Generally timer messages don't get through ( they are chucked) if I remember but it may depend on the type of window registered and there are so many types.
  Permalink  
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 341
1 Marcin Kozub 225
2 Praneet Nadkar 197
3 Sergey Alexandrovich Kryukov 190
4 Shweta N Mishra 161
0 OriginalGriff 8,149
1 Sergey Alexandrovich Kryukov 7,287
2 DamithSL 5,614
3 Manas Bhardwaj 4,986
4 Maciej Los 4,910


Advertise | Privacy | Mobile
Web03 | 2.8.1411023.1 | Last Updated 31 Oct 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100