1. Technology

Focus and Select

What is the difference between Focus and Select?


Updated September 25, 2007

This article started as an explanation of the slightly unfamiliar CanFocus and CanSelect methods that give more meaning to Microsoft's claim that Visual Basic .NET is a language that is now "industrial strength". But, in my mind, how important they are is still an open question. Writing about CanFocus, The Visual Basic 2005 Cookbook puts it this way: "Event-driven programming can lead to many runtime surprises based on timing. ... some situations may arise in which the focus action fails."

But what does the book mean by "can lead to many runtime surprises". That's the problem with books sometimes. They don't explain some of these claims. I've looked high and low for an example where this actually causes a problem. The Cookbook suggests that modal forms are an example of where problems can come up, so I programmed an example using a modal form. That just raised more questions. As I looked for a really good reason to use CanFocus, I started looking for differences with CanSelect and I didn't find any. So I started looking for differences between Focus and Select and didn't find any.

This article retraces these experiments and you'll learn everything you need to know about how to use all of these methods, as well as something about debugging. At the end, I'll show you a conclusion that you might find surprising.

Since the Cookbook suggested that a modal form could cause problems, I created a simple program with two forms as shown below.

Click Here to display the illustration
Click the Back button on your browser to return

The idea was to show that code executed in a parallel process to set the focus on the top button would fail when a modal form was displayed. To create a parallel process, I added a Timer component to the project that executed the Focus method for the top button:

Private Sub Timer1_Tick( _
   ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
   Handles Timer1.Tick
   Debug.Print("DefaultButton Should Have Focus")
   If DefaultButton.Focused Then
      Debug.Print("DefaultButton IS focused.")
      Debug.Print("DefaultButton IS NOT focused.")
   End If
End Sub

As the illustration shows, the statement ...


... silently fails as long as the modal dialog form is open. This could cause problems because an "enter" key is the same as a mouse click (in this case) and if the user is expecting to be able to press "enter" and perform a default action when the main form becomes active, it could be confusing when something else happens instead. That's something to keep in mind. But in this particular case, the fix is easy. Simply set the focus to DefaultButton in a Form1.Activated event. No problem. This example fails to demonstrate a real requirement for CanFocus.

In an effort to discover a better example, I decided that I needed to better understand what the difference between Focus and Select really was. I started by reviewing the "official" definitions of Select and Focus at Microsoft. Here's how Microsoft defines Select:

Control.Select Method
Activates a control.

It is, at least, brief. But it leaves me wondering what "activates" really means.

Here's the definition of Focus at Microsoft:

Control.Focus Method
Sets input focus to the control.

Since this didn't really tell me anything, I wrote a second experimental program to check out what Focus and Select actually do in program code. In the simple form below, each button does just one thing.

Click Here to display the illustration
Click the Back button on your browser to return

Each button executes code similar to this:

Private Sub SelectTheButton_Click( _
   ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
   Handles SelectTheButton.Click
End Sub

The button, "A Different Button" is just there to reset the focus somewhere else visible by clicking on it and doesn't actually do anything.

If success is finding a critical difference, this program was a total failure. I could see no difference whatsoever. I remembered that there were some additional comments on Microsoft's page explaining the Focus method:

The control can have the input focus while not displaying any visual cues of having the focus. This behavior is primarily observed by the nonselectable controls listed below, or any controls derived from them.

A control can be selected and receive input focus if all the following are true: its ControlStyles.Selectable style bit is set to true, it is contained in another control, and all its parent controls are both visible and enabled.

The Windows Forms controls in the following list are not selectable. Controls derived from these controls are also not selectable.

LinkLabel (when there is no link present in the control)

"Ah Hah!" I said to myself, "This is one of those methods that only applies to a few controls!" So I coded yet another experiment to demonstrate that. My guess turned out to be wrong. See why on the next page.

  1. About.com
  2. Technology
  3. Visual Basic
  4. Using VB.NET
  5. Focus and Select

©2014 About.com. All rights reserved.