MFC and modal message boxes.

Question

0.00/5 (No votes)

See more:

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 4:32am

dlavrantonis

Updated 31-Oct-11 4:43am

RaisKazi

v2

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Nish Nishant · Answer 1 · 2011-10-31T04:42:00

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).

Posted 31-Oct-11 4:42am

Nish Nishant

Updated 31-Oct-11 4:46am

v2

Comments

dlavrantonis 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 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)

rj45 · Answer 2 · 2011-10-31T11:55:00

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.