How can I *simulate* an AfxMessageBox?

[cyrano]

I have a bug that is fixed by simply putting in an AfxMessageBox message. However, I don't want the message box window to pop up and be visible to the user. How can I make Windows / the app / whatever think that an AfxMessageBox just popped up WITHOUT actually showing one?

I've tried InvalidateRect, ActivateFrame, Activate... What else can I try? What messages get posted when an AfxMessageBox gets posted?

(and I don't want to pop up the box then hide it-- from my experience, the user can still see the message box for a split second)

Thank You

[Paul McKenzie]

I and almost any other competent Windows programmer would not call what you did a "bug fix". You really have not fixed anything, except do a hack which may not work on other systems.

Instead of fighting with the Windows OS (the AfxMessageBox is a call to the API ::MessageBox() function, whicn in turn can be modal, system modal, application modal, and the dialog goes in a closed message loop, etc. etc.) why not tell us what the real problem is that you were having before resorting to this? Maybe someone can help you with that problem first.

Regards,

Paul McKenzie

[cyrano]

Thanks Paul. Yah, I know it's a hack, and it is a *last* resort. I've just spent way too much time on the problem.

Thanks again

[aj454]

Why don't you tell something about your bug. If not fixed, it will haunt you all the time. How many AfxMe....() box you will put to satisfy all the bugs.
regards.

[Paul McKenzie]

Well you haven't told us what the bug is. Just let us know, and people here can give you suggestions on what you may be doing wrong.

As I stated, putting the AfxMessageBox is not the "last resort" and is just voodoo that you discovered. If you plan on deploying the application to other users, expect calls from them letting you know that your program fails. Then you'll say to yourself "I don't understand, the AfxMessageBox was supposed to fix that". You'll feel like the Dutch boy trying to stop the dam from leaking.

Regards,

Paul McKenzie

[330xi]

Have the same "bug fixing" And i also need to simulate AfxMessageBox

"Tell us what the problem is"
Okay

In OnCreate of MainFrame I have a function call that connected with two other custom classes (children of view and dialog), one of them connected with hardware.
I have calling this function in 2 other places.
And two types of starting program: with hardware connected/hardware disconnected

In first type of start everything is fine
In second type of start function works properly everythere except OnCreate.

[Igor Vartanov]

So why wouldn't you call your function somewhat later but not in OnCreate? Try OnCreateClient.

[GCDEF]

Have the same "bug fixing" And i also need to simulate AfxMessageBox

"Tell us what the problem is"
Okay

In OnCreate of MainFrame I have a function call that connected with two other custom classes (children of view and dialog), one of them connected with hardware.
I have calling this function in 2 other places.
And two types of starting program: with hardware connected/hardware disconnected

In first type of start everything is fine
In second type of start function works properly everythere except OnCreate.

A 12 year old thread. I think that may be a record.

[330xi]

So why wouldn't you call your function somewhat later but not in OnCreate? Try OnCreateClient.

my function connected with a plenty of initialization commands and variables that exist only in OnCreate. I've tried but it cause a tree of run-time errors.

But on this exact topic, if in next 12 years someone choose such idea:

In my case any dialog is suitable to make my program run as I want it to. It must be visible for 100 ms. So:

A new class CDialog
in OnInitDialog:

SetTimer(1,100,0);

in OnTimer:

EndModalLoop(IDOK);

in callPlace:

Safe s;
s.DoModal();

In Resaurces set feature "Transparent" - true.

[darwen]

Actually it sounds like this is a windows message loop problem.

By calling show dialog the dialog is setting up its one message loop which pumps the window's messages around.

The hardware access (sorry - is it though a 3rd party library) might use windows message loops in its operation (SendMessage and the like).

Maybe you're initialisation of the hardware might be better inside of a button click ?

Darwen.

[330xi]

Actually it sounds like this is a windows message loop problem.

By calling show dialog the dialog is setting up its one message loop which pumps the window's messages around.

The hardware access (sorry - is it though a 3rd party library) might use windows message loops in its operation (SendMessage and the like).

Maybe you're initialisation of the hardware might be better inside of a button click ?

Darwen.

oh, thanks!) At least I know the general form of my problem now. I'm sure it helps me to find other people experience in solving it and explore it better.