Too many wm_AppActivates spoil the Application ...

  • Thread starter Thread starter Phill. W
  • Start date Start date
P

Phill. W

I've written my own replacement for MsgBox, that I do all kinds
of wierd things with. So far, it's done everything I need it to.
Until now ...

I'm trying to use it in an application that is "sensitive" to the
difference between the Activate and AppActivate "events" (the former
being handled by overriding OnActivated, the latter by interrogating
the Message argument to WndProc).

For some odd reason, when I use my MsgBox replacement, I'm
getting not one, but /two/, WM_APPActivate messages in the
calling form - values seen in WndProc:

Msg=(28), hWnd=(3081424), LParam=(2004), WParam=(0)
Msg=(28), hWnd=(3081424), LParam=(2004), WParam=(1)

This triggers all kinds of things in the application that I don't want
to happen for an "internal" dialog. Oddly, using the normal
MsgBox instead, I get /no/ wm_appactivate messages at all!

Since my replacement is little more than a Form within which I call
ShowDialog(owner) on itself, can anyone suggest where these
extraneous messages might be coming from?
Surely the CLR can't see every form in a single application as a separate
application... ?

TIA,
Phill W.
 
Phill. W said:
For some odd reason, when I use my MsgBox replacement, I'm
getting not one, but /two/, WM_APPActivate messages in the
calling form - values seen in WndProc:

Msg=(28), hWnd=(3081424), LParam=(2004), WParam=(0)
Msg=(28), hWnd=(3081424), LParam=(2004), WParam=(1)
Click to expand...

If I'm not mistake, I believe that the WParam indicates what is
happening. If WParam is False, then the window is being de-activated
and if True, the window is being activated.

Could it be that one message is occurring when the main form is no
longer the active form and the other is when the MsgBox is becoming the
active form?

Just a thought
 
And after a little research, there should be two messages. One to the
app whose window is being deactivated and one to the app whose window
is being activated.
 
Chris Dunaway said:
And after a little research, there should be two messages. One to
the app whose window is being deactivated and one to the app
whose window is being activated.
Click to expand...

After some digging, I found the same thing myself - wm_activateapp's
/do/ come in pairs. However, this still belies my [rather more
significant]
problem in that I wasn't expecting to get /any/ of them in the first place!

My replacement form is in a separate, GAC-"registered" assembly
but, even so, that still shouldn't force execution out into a separate
Thread, should it?

Alternatively, since the wm_activateapp includes the ThreadID of the
"other" process, is there any way I can work out what /my/
application's ThreadId is and only call the "OnAppActivate" code if
the ThreadID's differ? (If I'm regaining "focus" from myself, then it's
not a "genuine" Application Activation).

Regards,
Phill W.
 
Phill. W said:
problem in that I wasn't expecting to get /any/ of them in the first place!
Click to expand...

That is my understanding as well. Since the forms are being shown from
the same application, I wouldn't think that that particular message
would occur. Did you see them while in the debugger? Perhaps the act
of switching from the debugger might have had something to do with it.
"other" process, is there any way I can work out what /my/
application's ThreadId is and only call the "OnAppActivate" code if
Click to expand...

You can get your thread id by calling AppDomain.GetCurrentThreadId
 
Back
Top