In GUI applications, Focus is the boolean property referring to which component is currently selected by the user or currently active. The simplest example of this that we've all seen is when you select a TextBox and the I-cursor appears, indicating that you can begin typing content in this particular field. Sometimes, you can use the tab-key to iterate through a list of selectable components, each gaining/losing Focus in turn — you might do this with input forms that require multiple pieces of input, such as your mailing address or credit card information.

There are six Events triggered by components gaining/losing Focus. And to make matters worse, the order these events are triggered is different for when you gain/lose Focus from tab-ing to components or mousing to them! Why? ... This isn't a rhetorical question: I'm genuinely asking you, the reader, because I have no idea!

When using the keyboard to iterate through the available components:

1. Enter
2. GotFocus
3. Leave
4. Validating
5. Validated
6. LostFocus

When using the mouse:

1. Enter
2. GotFocus
3. LostFocus, moves up from last to third
4. Leave
5. Validating
6. Validated

To get started with using Focus, you can... focus on just two Events: GotFocus and LostFocus.

The most common context in which we're responding to gained/lost Focus are input fields that contain "shadows" we use to help indicate to users what type of input they're expected to provide, or the format for which we would like their input to follow. This is hinted at with the phone number example on the page about Keyboard Events. We can initially present the TextBox as having a shadow of the format we would like to insist on:

(XXX) XXX-XXXX

Then once we GotFocus, we update the text color to black, and remove the shadow. Assuming the user begins typing in numbers, we use the keyboard events to automatically insert ( and - characters as necessary. Or if the user moves Focus to another component without typing in a phone number, we can revert the text-color to the #666666 grey color, and return the shadow.

You can also use this to highlight fields that a user needs to provide input for, or is otherwise required within the form. For example, if you hit "Submit" without completing your mailing address, you can iterate over the various input fields to find the first one that's blank, call the Focus() method of that component to automatically give it focus so the user can (ideally) immediately begin typing (as opposed to making them drag their mouse cursor all the way over to where the input field is), as well as to display a "This field is required" type of message.

Another neat implementation of Focus events relates to ToolTips in some ways, in that we can use first-time Focus on a component to trigger the display of a helpful hint or explanation as to what this field is intended to capture. This can be particularly helpful on technical forms, where selecting an input field brings up a small dialog window about what you should enter here, or the conditions upon which input is required. This can be especially applicable to game design, as part of a tutorial portion.

To explicitly define the order in which elements should be iterated to by continuously pressing the tab-key, you can modify each component's TabIndex property, where 0 is the first component and 4 is the fourth component to be iterated to. (Since tabbing over from 0 to 1 carries focus to the first component you can iterate to.)

In conclusion: Focus is another mechanism in GUI design that helps us as software developers build more responsive, intuitive, and helpful applications, in concert with keyboard and mouse events. The more we can do to anticipate user needs or behaviors, the better received our application will be.