I always thought it was odd that WPF has both TextBlock and Label. They both are responsible for displaying a small amount of text. Every piece of documentation about Label I have read justifies its existence by mentioning that it allows for access keys (a.k.a. mnemonics). Access keys allow you to hit Alt + SomeKey to quickly interact with a control in the UI, such as hitting Alt + O to click an “OK” button. My thought has been, “Why not just add support for access keys to TextBlock and get rid of Label?”
Recently I discovered some reasons why it makes sense for Label to exist. The rest of this blog post sheds some light on that obscure topic. Throughout this blog post we will refer to a demo application which looks like this when you first run it:
The “Username:” text is a TextBlock and the “Password:” text is a Label.
TextBlock is not a control
Even though TextBlock lives in the System.Windows.Controls namespace, it is not a control. It derives directly from FrameworkElement. Label, on the other hand, derives from ContentControl. This means that Label can:
- Be given a custom control template (via the Template property).
- Display data other than just a string (via the Content property).
- Apply a DataTemplate to its content (via the ContentTemplate property).
- Do whatever else a ContentControl can do that a FrameworkElement cannot.
Below is a fragment of the class inheritance hierarchy containing Label and TextBlock:
Label text is grayed out when disabled
When a Label’s IsEnabled property returns false its text is “grayed out.” TextBlock does not have this behavior by default. Here is what the demo app looks like when the input area is disabled. Keep in mind that the “Username:” text is a TextBlock and the “Password:” text is a Label:
The reason Label text turns gray when it is disabled is due to the fact that Label’s default control template has a Trigger which explicitly sets the Foreground property when IsEnabled is false. Here is that Trigger from Label’s default control template:
If we really wanted TextBlocks to appear grayed out when disabled, we could repurpose that XAML seen above into a Style which is applied to TextBlocks (as seen in the demo project available at the end of this post).
Label supports access keys
This is the standard explanation of why Label exists. You can associate a Label with another control, such as a PasswordBox, and allow the user to type an access key defined by the Label to set focus to the other control. The access key is represented in the UI by drawing a line under the appropriate character. If the user presses the Alt key and then the designated “access character” the target control will be given focus.
Here is what the demo application looks like after the user presses the Alt key:
Notice how every piece of text in the UI has an access key indicator, except for the “Username” TextBlock. The “Password” Label and its target (a PasswordBox) were declared like this:
Label is much heavier than TextBlock
So far we have examined why Label can be considered better than TextBlock, but now its time to discuss the benefits of using a TextBlock instead. Label has a higher runtime overhead than TextBlock. Not only does Label inherit from two classes further down the inheritance hierarchy than TextBlock, but its visual tree is much more involved.
I snooped the visual tree of the demo app to see what was really going on when you create a Label with an access key defined. Below is a screenshot of Snoop displaying the visual trees of both the “Username” TextBlock and the “Password” Label (with an access key defined):
The “Username” TextBlock’s visual tree contains no child elements. The Label, however, is much more involved. It has a Border, which contains a ContentPresenter, which hosts an AccessText element, which finally uses a TextBlock to display the text. So it turns out that using a Label is really just an elaborate and customizable way of using a TextBlock.
Links
ContentPresenter.RecognizesAccessKey Property
How to: Create a Control That Has an Access Key and Text Wrapping
Download the demo
Download the demo project here: Label vs TextBlock (demo project) Be sure to change the file extension from .DOC to .ZIP and then decompress it.
Josh,
Wow! Great article. I’m going back and change my combobox code to use TextBlock’s instead of Labels.
I”m getting snoop too. So much to learn.
Happy 4th,
Karl
Thanks Karl! Happy 4th of July to you as well.
Josh
Love your posts!
Who would have thunked it! Interesting!
I also think I need to get snoop 🙂
Josh,
The Snoop program you recommend, have you built it and/or used it with VS 2008 beta 2? It seems to crash any time I try to snoop a program that I have built with the latest beta. Is this just me or is Snoop currently only workable with VS 2005 & WPF extensions installed?
-Brandon
Brandon,
I don’t know if Snoop works with Beta 2, haven’t tested it. I suspect the problem might be that the WPF app compiled in Beta 2 is using the .NET Framework 3.5, instead of 3.0. I think there’s some way to compile against the framework version of your choice in Beta 2, so try compiling against 3.0 instead. That might work.
Josh
Good idea Josh, unfortunately it didn’t work 😦
Don’t know how I’m going to survive without it… 🙂
The other difference I stumbled into is that unlike TextBlock’s, Label’s color is not inverted when it appears on the DataTemplate of ListBox’s item and that item gets selected. See screenshot here: http://img172.imageshack.us/img172/5231/tbvslabeljd1.jpg , “File size” and its respective value are implemented via Labels, other info – via TextBlocks.
Your snooping findings were a revelation, I thought MS claims that “using Label can be advantageous because it requires even less resources (lighter weight) then a TextBlock” (here: http://msdn2.microsoft.com/en-us/library/aa969821.aspx) were suspicious, now I know for sure.
Thanks for your immensely helpful blog!
Thanks Sergei. I wasn’t aware of that quirk of the Label. Good find!
Josh
I really got to learn a lot from this site. Excellent!!
I have a button by name “Add All” and i want the acess key to be AA.How do i assign it?
Is there any way wherein i can Assign access keys to textblock? I need to assign access keys to a textblock. I can’t replace it with a label because label doesn’t have text wrapping properties
developer,
You cannot have an access key of “AA”. You can have it be Alt + A, by putting an underscore (_) before an “A” in the display text.
AFAIK, you cannot add access keys to a TextBlock. The reason Label exists is so that you can give an access key for the next control in the tab order.
josh
Thank you so much for the reply..
I actually wanted a label a label which couldwrap and also to which i cud assign an access key.. so i added this piece of code and it worked
Require master for project _creation
Thank you so much for the reply..
I actually wanted a labelwhich couldwrap and also to which i cud assign an access key.. so i added this piece of code and it worked
Require master for project _creation
I want to assign two access keys to the same label.Is that possible in xaml. Also, how can i assign access key to an image
Really MS has no way to document WPF properly, you got real good documentation, MSDN really sucks, till now I am dissassembling every System DDLs to learn WPF internals.
No doubt, MSDN has not explained Control Life Cycle which is damn important to understand behaviour and write custom control.
Another big problem of WPF documentation is, different names, Avlon and WinFX and WinFS and if you search anything in Google, results are so confusing, even in MSDN subscription, its a big big Junk Yard to search anything. I was highly irritated by whole MSDN but your this article made some of concepts clear and I could solve my problems regarding TextBlock and Label.
Thanks buddy,
– Akash Kava
I changed the Label foreground to a color other than Black, and IsEnabled = false does not make the Label disabled (text greyed out) anymore. Any thoughts?
Thanks!
I’m a little confused… Is the fact Label does not invert its color upon being selected in a template a bug? Why does it behave that way?
Hey Josh, thanks for clearing this up. Well written and to the point.