I recently had a requirement where a user was able to perform an action externally to my application, and my application then had to detect this for processing.
I could of course just had a poller running away in the background to check, but as the requirement also needed user input, why not just wait until the user switched back to my application, then check and deal with accordingly?
Form object has an
Activated event and a
Deactivate event that (very logically!) are fired when your
form is activated and deactivated.
Brilliant! Well, it would be - if your application is a single
form application that doesn't show any window ever. Including
message boxes. Still, you could do it that way, if your
processing was absolute and always done there and then. In my
case, I had to give the user a choice - if they said no, then I
would simply ask them again later (ie the next time the
application was activated). But if I stuck with the
event it would mean they would get prompted after displaying
another dialog in my application... probably not the sort of
behaviour you want to exhibit.
So how does Windows do it? It does it via the use of the
WM_ACTIVATEAPP (MSDN reference). Windows sends this
message when a window belonging to a different application than
the active window is about to be activated. It's also good
enough enough to send it to the window about to be deactivated
too, so this one message can cover both activation and
Even after all these years of being a C# developer, I still marvel at just how easy this stuff is. In my VB6 days, I could (and did) do exactly the same thing, but it was difficult to implement and fun to debug.
To handle Windows Messages in C# we just need to override the
WndProc method on your
Form. Then we can check for the
WM_ACTIVATEAPP message arriving and handle it accordingly.
According to the MSDN docs,
lParam contains the thread
identifier, however we can safely ignore this.
WParam property on the
Message struct) is the important bit.
It's a simple true or false value (true for activation, false
otherwise) and so we just need to check it isn't zero and we're
good to go.
You could just stick that override in your applications form and use it like that, but as always we should think a little bit about the future and promote some code re-use! In this case, I'm going to create a pair of events and add them (along with the override) to a base class, so next time I want this functionality the events are sitting there waiting.
You can download the demonstration code from the end of this post, but here's a simple example of the code in use:
ApplicationDeactivated events are all being used (well, their
overrides are) to log information. If you run the example, you
will see that
Deactivate are called whenever
the form itself is processed, ie from opening a dialog or
displaying a message box, whilst the
ApplicationDeactivated events are only called when I switch to
In the above example, the
ApplicationDeactivated events are raised as expected -
including if you already have a modal dialog open in your
application. Just something to keep in mind if you use this sort
of functionality to prompt the user for an action. If your
events are showing their own modal dialog, that's fine, but if
they are trying to do something else, such as set focus to a
control, or open a floating window - then you're likely to run
- 2013-12-29 - First published
- 2020-11-21 - Updated formatting
Like what you're reading? Perhaps you like to buy us a coffee?