All → Development → .NET

Notice: Using the "fix" below can result in the form's Activated event not being fired when it is restored from the taskbar. I guess this isn't a proper solution, after-all. Adding checks for the form being minimised/restored may be a solution but the Form class is firing those events are weird times, so.,,

Notice 2: I've added another version below.

A couple of new categories for this blog: Development and .NET. I'm surprised I haven't written more on programming in general, to be honest. I think I'll have to port across my post from an older blog on the whole BadImageException problem which drove me mad for far too long.

But, let's continue with the subject of this post: the Form.Activated() event incorrectly firing on a Form.

Quite a few years ago I created my own Metro-style form based on the idea of Microsoft's flat-style interface. Metro was approximately a couple of years away from release and there wasn't really any screenshots of what it would look like. I ploughed on with my version - including a break of a year because it took a long time to get it working correctly as working with forms that have their FormBorderStyle set to None in .NET is just outright annoying. This changed in WPF, but we're using WinForms here. #winforms4lyfe

The biggest issue was getting Windows to treat the borderless form as a true window; it just didn't give a crap about it. A quick way to tell if Windows regards a form as a true window is to minimise it to the taskbar. Does it immediately disappear from view? It's not a true window. Does it animate down into the taskbar? It's a true window.

There were two issues remaining (that I remember, anyway): restoring the window from its minimised state causes the window to gain an extra X number of pixels on its height. That's still an issue and seems random as to which form it affects. The fix I put in-place seems to work most of the time, but regardless, the child controls gain extra height with/without the form growing in size. Clearly more work to be done, there.

The second issue which I'm going to talk about here is the form's Activated() event firing when the form hasn't actually been activated. I don't know why this occurs, but it's annoying and obviously unexpected.

It seems somewhat random when it happens, but here's how it generally goes:

While the form is activated, deactivate the form by clicking outside of it and then move the mouse cursor over the form without clicking; chances are the form will receive the Activated() event. Despite this event firing, the form isn't actually activated.

This causes a problem in my particular case because I handle and expose the activation event via a WindowActivityChanged() event, and I also change the form's visual style depending on its active state.

For example, here's a (currently work-in-progress) form that's active:

And here's that same form when it has become inactive:

As you can see, having the form become active when it actually isn't is confusing to the user. And extremely irritating to me.

My first quick go at fixing this seems to work; I'll have to keep testing it over the long term but it seems like it may have solved it. Not a fan that I have to do this in the first place, but what can ya do?

Have this at the first line(s) within the Form_Activated() event [VB]:

' Filter out any spurious activations.
If Not ActiveForm Is Me Then Exit Sub

Here's another version (see notice at top of this post):

If Me.RectangleToScreen(Me.DisplayRectangle).Contains(Cursor.Position) AndAlso Not ActiveForm Is Me Then Exit Sub

ActiveForm is a Read-Only property on the base Form class and contains a reference to the form that is currently active (within our application; it's not system-wide or anything!), so we're checking to see if the active form is actually me (or this in C#) rather than just blindly accepting the fact.

It appears ActiveForm is set before Form_Activated() is fired, so it does what we want.

I'm not sure if it's worth putting a check into the Form_Deactivated() event to ensure that the form is truly deactivated, but I don't recall ever running into that particular problem. I guess time will tell.