Focusing on cue

One of the challenges of implementing the Winforms behaviour from scratch is emulating all the little quirks that have accumulated over the years on Windows and that show up in .NET.

One of these little thingies that make for big headaches is the visual focus cue. You know, that little rectangle that appears in controls whenever they have focus. Well, it turns out this apparently simple thing as showing a rectangle drawn on a button is not so simple at all, because it doesn’t show up every time a control has focus… there are certain rules that control when it should appear (the headache part :p)

It all started when a few bugs started showing up on the Mono Bugzilla, filed by people comparing the same application in Mono and MS.NET and discovering that the focus rectangle was being drawn in one but not in the other… or vice-versa.

After a quite lengthy chat on the #mono-winforms channel, I had several different tests and quite a few links with which to start tackling the problem of figuring out exactly what rules apply when deciding whether to show the focus rectangle or not. I learned that there are two types of visual cues on Windows: the focus rectangle, and the keyboard shortcut underlining. I further learned that there is an option on Windows that controls the keyboard underlining cue… and that this option also controls the focus rectangle cue, but it doesn’t say so when you change the setting. Don’t you just love it? Eh. The option is available under Display / Effects / Hide underline…

Anyway, in theory, the visual cues should work like this: since that checkbox controls both the focus cue and keyboard cue, if it is checked it means that the keyboard cue will only show up if you press the Alt key, and the focus cue will show up if:

1. you press Tab, or navigate between controls with the keyboard, or
2. you activate the window with the keyboard. This second part is important, because sometimes people don’t notice how they activated the window, and so don’t quite get the behaviour they think they should. Activating the window means opening it with the keyboard, for instance, instead of with the mouse.

if, on the other hand, the option is not checked, the both the keyboard and the focus cues will show up regardless of how you activate the window or how you navigate between controls in it.

Now, since there has been a lot of reports of different behaviours when this checkbox is checked or unchecked that don’t quite fit with the theory, it stands to reason that there is something else fiddling with these options. It’s quite possible that certain themes or tweaking applications change one of these options but not the other, so that certain systems don’t exhibit the behaviour shown above.

Finally, all of this reeaaallly doesn’t matter all that much because there is no such equivalent in Linux, , so essentially Mono should behave according to a default behaviour chosen to actually make sense :) and stick with it.

Isn’t this fun? :D

references:
http://blogs.msdn.com/saraford/archive/2004/04/16/114935.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/05/03/414317.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/KeyboardAccelerators/AboutKeyboardAccelerators.asp