One of the new features in RB2005r3 is the ability to allow certain controls to accept focus on Windows. These controls are invariably the non-system controls; basically, Mac concepts brought over into Windows such as the BevelButton or DisclosureTriangle.
Previously, you had no choice -- these items were simply inaccessible to the keyboard. They weren't included in the tab order, and they could never get keyboard focus.
Well, that's just plain terrible. These controls most certainly should be allowed to have keyboard focus! However, in certain instances, they should not. That's what this blog is all about.
Since all of these controls were implemented as internal plugins, I first had to modify the plugins SDK to allow you to determine whether your control wants to accept focus or not. This way the plugin can communicate its intentions back to the runtime so that we can either allow the control to accept focus or to deny it focus and skip to the next control in the tab order. So now each plugin control which can be interacted with (ScrollBar [which isn't a plugin control], BevelButton, DisclosureTriangle and UpDownArrow) got a new property: AcceptFocus as Boolean.
This property is what lets you determine whether you want the control instance to be able to get focus or not. But how do you use it properly?
If you were thinking: always turn it on, that'll stop Aaron from whining.... then you're partially wrong. Each control has a different set of rules, which I'll explain via examples.
We'll start with the easy one -- the DisclosureTriangle. This control should always have AcceptFocus set to true. When doing this, it means you can tab into and out of the control, and hitting space or enter will cause the control to toggle its facing.
The BevelButton is a bit trickier. It's original purpose within REALbasic was to provide users with a way to create a poor-man's toolbar on Windows. And toolbar items on Windows do not get keyboard focus (unless they are standard OS controls such as an EditField or a ComboBox). This is because a toolbar item is simply a pretty representation of common actions found within a menu. You should never have a toolbar item without a menu -- and so that means all toolbar items are still accessible since you can navigate the menus using the keyboard. So! If you're using your BevelButtons as a toolbar item on Windows, then you should leave AcceptFocus set to false. However, if you're using it for any other purpose, then the user should be able to tab into it like a normal button. So, using the RB2005 Find dialog as an example, the recent items and favorites BevelButtons have AcceptFocus set to true because the user has no other way to access that functionality without using the mouse otherwise. In case you're wondering, hitting space or return will cause the BevelButton's action event to fire. This will also drop down things like its menu, if appropriate.
Moving on down the trickiness scale, we come to the UpDownArrows control. If you're using this control in conjunction with another control which does not receive keyboard input, then you should let the control AcceptFocus. So, for example, if an UpDownArrow modifies the text of a StaticText control in the window, then you want the UpDownArrow to get keyboard focus so that it can be useful. (You use the up and down arrow keys to interact with the control). However, if you're using the control in conjunction with another control which can accept keyboard input, such as an EditField, then you do not want the UpDownArrows to accept focus. This is because the keyboard input should be taking place within the EditField. So, as a user, I'd tab into the EditField (which contains, say, a number), and hitting up or down arrow keys should modify that number. Hitting tab should take me out of the field -- not to the UpDownArrows control. As you can see, the line between when to accept focus and when not to is getting a bit more blurry!
Finally, there's the ScrollBar control. In previous versions of REALbasic, our scrollbar would always accept keyboard focus. It had the opposite problem of all the other controls I've discussed today. However, this too is no good. A scrollbar has a very strange set of focus rules. It's actually easier to talk about when it should receive focus than when it should not. If a scrollbar is being used as a stand-alone control on a window (basically, being used for the same purpose as a slider control), then it should accept focus. That's the only time. So if you're using a scrollbar at the edges of a window, for example, it should *not* receive keyboard focus.
So that's the run-down of the new AcceptFocus property additions in RB2005r3. Hopefully this clears up when and why you should care about this new property. It may seem like a very minor thing, however, it makes your applications more professional in the Windows market and improves your accessibility, which is always a good thing.
Leave a comment