Click here to Skip to main content
15,868,093 members
Articles / Desktop Programming / WPF

Setting the Initial Focus in WPF

Rate me:
Please Sign up or sign in to vote.
4.95/5 (14 votes)
14 Apr 2010CC (Attr 3U)1 min read 94.7K   34   13
Shows how to set the initial focus in XAML

In WPF dialog boxes, I quite often see some code which looks like the following code example:

C#
private void OnLoaded(object sender, EventArgs e)
{
    this._textSearch.Focus();
}

This is usually accompanied by some XAML that looks like the following XAML example.

XML
<Window ...
        Loaded="OnLoaded">

Occasionally, I also see the event being set up in the constructor. For some reason, this really gets on my nerves. I prefer to see event handlers defined in the XAML. I’m not quite sure what my objection is; I think I just prefer to see all the UI things in one place.

What this actually achieves (as you can probably work out), is that the control (in this case, a TextBox) named _textSearch has focus when the dialog box is loaded. In actual fact, WPF provides a much easier way of setting the initial focus by using the FocusManager. The FocusManager provides a set of static methods, properties, and events that you use to determine and set the focus scope[1] and to set the focused element within the focus scope.

So, using the FocusManager, you don’t need to handle the Loaded event and manually calling the Focus method as shown in the previous code examples, you can simply set the FocusedElement on the FocusManager as shown in the following code example:

XML
<Window ...
        FocusManager.FocusedElement="{Binding ElementName=_textSearch}">

Simple, neat, all in one place, and no code-behind :)

[1] For more information about focus scopes, see FocusManager Class on the MSDN web site.

This work is licensed under a Creative Commons Attribution By license.

License

This article, along with any associated source code and files, is licensed under The Creative Commons Attribution 3.0 Unported License


Written By
Software Developer (Senior)
United Kingdom United Kingdom
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
SuggestionAnother Global Solution Pin
Tom John28-Aug-13 0:21
Tom John28-Aug-13 0:21 
GeneralDoes not work in all (common) situations Pin
Xcalllibur6-May-10 18:16
Xcalllibur6-May-10 18:16 
GeneralRe: Does not work in all (common) situations Pin
Tom John28-Aug-13 0:14
Tom John28-Aug-13 0:14 
GeneralRe: Does not work in all (common) situations Pin
Derek Lakin28-Aug-13 0:36
Derek Lakin28-Aug-13 0:36 
QuestionHow do you change focus in XAML? Pin
ldyc23-Apr-10 1:43
ldyc23-Apr-10 1:43 
GeneralXAMS vs. Code Behind Pin
DaProgramma13-Apr-09 11:25
DaProgramma13-Apr-09 11:25 
GeneralRe: XAMS vs. Code Behind Pin
Derek Lakin13-Apr-09 21:50
Derek Lakin13-Apr-09 21:50 
GeneralRe: XAMS vs. Code Behind Pin
DaProgramma14-Apr-09 6:39
DaProgramma14-Apr-09 6:39 
Derek Lakin wrote:
At runtime the binding will fail silently (apart from a really helpful message in the Output window ) and the application will continue quite happily.



I definitely do not want this behavior. It might be acceptable when setting the initial focus fails, but it is not acceptable when, for example, some data binding fails silently. Summary: Markup extensions with their implicit dynamic evaluation behavior ( "{Binding ...}" ) are EVIL from a correctness / maintenance point of view. I want strong typing.

<blockquote class="FQ"><div class="FQA">Derek Lakin wrote:</div>Generally, I name my controls according to their purpose, not their type, so that when I feel the need to change the control from one type to another, I don't need to rename them. However, even if you put the focus management in the code-behind, renaming the control in the XAML will still require you to update the code-behind. Admittedly, it will be found by the compiler for you, but you're not testing your application very well if you apply something and then never test it.</blockquote>

I am not talking about changing types of controls. I talk about the situation when you start with having a filed/property/control "name" and later need to divide it into "firstname" and "lastname". With Agile Development, things like that happen quite often, and thats why VS supports refactoring. I dont's want to give up compiler support for that.

And, yes, I am not testing my apps with automatic tools, because this is not worth the effort. We have competitive advantage by NOT having unit tests. It might be a heritage from my C++ days, but when it compiles fine, it should have no programmer errors. It might have logical or conceptual errors, but these you do NOT get with unit tests either.
GeneralRe: XAMS vs. Code Behind Pin
Derek Lakin14-Apr-09 6:53
Derek Lakin14-Apr-09 6:53 
GeneralRe: XAMS vs. Code Behind Pin
DaProgramma14-Apr-09 7:12
DaProgramma14-Apr-09 7:12 
GeneralRe: XAMS vs. Code Behind Pin
Derek Lakin14-Apr-09 21:28
Derek Lakin14-Apr-09 21:28 
GeneralThanks Pin
0xfded7-Apr-09 14:10
0xfded7-Apr-09 14:10 
GeneralRe: Thanks Pin
Derek Lakin7-Apr-09 22:06
Derek Lakin7-Apr-09 22:06 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.