First of all, thanks for answers! 9 total answers. Thank you.
Bad news: all of the answers had some quirks or didn't work quite right (or at all). I've added a comment to each of your posts.
Good news: I've found a way to make it work. This solution is pretty straightforward and seems to work in all the scenarios (mousing down, selecting text, tabbing focus, etc.)
bool alreadyFocused;
...
textBox1.GotFocus += textBox1_GotFocus;
textBox1.MouseUp += textBox1_MouseUp;
textBox1.Leave += textBox1_Leave;
...
void textBox1_Leave(object sender, EventArgs e)
{
alreadyFocused = false;
}
void textBox1_GotFocus(object sender, EventArgs e)
{
// Select all text only if the mouse isn't down.
// This makes tabbing to the textbox give focus.
if (MouseButtons == MouseButtons.None)
{
this.textBox1.SelectAll();
alreadyFocused = true;
}
}
void textBox1_MouseUp(object sender, MouseEventArgs e)
{
// Web browsers like Google Chrome select the text on mouse up.
// They only do it if the textbox isn't already focused,
// and if the user hasn't selected all text.
if (!alreadyFocused && this.textBox1.SelectionLength == 0)
{
alreadyFocused = true;
this.textBox1.SelectAll();
}
}
As far as I can tell, this causes a textbox to behave exactly like a web browser's address bar.
Hopefully this helps the next guy who tries to solve this deceptively simple problem.
Thanks again, guys, for all your answers that helped lead me towards the correct path.
There really is only one name in XAML, the x:Name
. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name
by using the RuntimeNamePropertyAttribute
on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.
The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement
introduces a Name property.
In general, a class does not need to store the name for x:Name
to be useable. All x:Name
means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.
So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.
In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.
Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.
See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.
Best Answer
Use a
TextBox
with these settings instead to make it read only and to look like aTextBlock
control.