[keitheweber]

I am new to WPF and xaml. I'm trying to figure out how to create placeholder text inside a textbox that is visible when the textbox does not have focus and doesn't have a value set (the Text is null).

I've been able to create a custom class that extends TextBox, but I am pretty sure that this can be done through xaml.

[Ryano121]

There is probably a better way of doing this without extending TextBox but its a solution -

http://c-sharp-snipp...older-text.html

[Skydiver]

The technique I'd seen in the past was having two TextBoxes occupying the same space, and a trigger that flips the visibility of the one with the placeholder. I can't seem to find a link to it anymore, but I remember thinking to myself that extending Textbox was more straightforward and involved less lines of "code" if you could call XAML code.

[tlhIn`toq]

I would never do the two textbox thing: That's just a hack.

Bind the textbox to a property, then set the default text of the property.

later when someone enters new text - that becomes the value of the property.

[h4nnib4l]

Check out the msdn page on textboxes. You might consider using events to clear the default textbox content when the textbox is clicked or gets focus. There are plenty of options, but as tlhIn`toq stated, swapping two textboxes is dirty, and honestly will require more work than doing it the right way.

EDIT: Fixed the MSDN link

This post has been edited by h4nnib4l: 07 June 2012 - 01:41 PM

[Curtis Rutland]

Wrong TextBox, h4nnib4l. This is about WPF.

It sounds like you are describing a Watermarked Text Box. If that's the case, I suggest the second answer on this thread:

http://stackoverflow...-textbox-in-wpf

Not the accepted one, but the one with many more votes.

[Skydiver]

Curtis Rutland, on 07 June 2012 - 12:30 PM, said:

It sounds like you are describing a Watermarked Text Box. If that's the case, I suggest the second answer on this thread:

http://stackoverflow...-textbox-in-wpf

Not the accepted one, but the one with many more votes.

I like that one too, but it doesn't answer the OP's question where he wants to implement it fully in XAML. The WatermarkService there is XAML + code. If he was going to do XAML + code, then there is the extended Textbox that he already has.

[Curtis Rutland]

Hmm, I didn't even notice that part of the question. I'm not sure it can be done entirely with XAML. But by creating an Attached Property, you're at least gaining re-usability for other types.

[tlhIn`toq]

So you want this in pure XAML with no code behind to bind the text to?

OK. CHEAT.

Tell the XAML you are binding to a property that doesn't exist, then set your placekeeper text in the FallbackValue of the property

<TextBox Height="154" HorizontalAlignment="Left" Margin="44,40,0,0" Name="textBox1" VerticalAlignment="Top" Width="317" 
                 Text="{Binding Path=dummyproperty, FallbackValue='THis is a bunch of placekeeper text'}"/>

[Skydiver]

tlhIn`toq, on 07 June 2012 - 11:01 AM, said:

I would never do the two textbox thing: That's just a hack.

Bind the textbox to a property, then set the default text of the property.

later when someone enters new text - that becomes the value of the property.

I think I went down this route before. I liked the simplicity and elegance of it because I needed to bind the input from the text box anyway.

It had issues though:
- It doesn't have the stylized faded text or whatever other style I wanted to use to denote that it was just a prompt.
- It makes handling required field difficult.
- Mismatching types

I can live without the pretty UI that I listed as the first issue, but the second issue was kind of a pain. It was relatively easy to distinguish the default text "Phone Number" from a valid entered phone number. I had to do some trickery with my Validator as I recall including breaking some encapsulation: my Validator ended up knowing what the default text was. "Weight" was kind of fun because I wanted to bind my text field to a numeric property, but now I needed to support text. I think with judicious use of TypeConverters I could have made things bind with a Decimal, but I figured since the ViewModel was supposed to mediate between the View and Model, it may as well mediate and return invalid or missing weight as the default text. Things got harder to distinguish when it came to "Address" (as well as other more free form fields like "Comments"). Yes, it is a really low probability that somebody's address will be "Address", but what if their address really is "Address"?

This post has been edited by Skydiver: 07 June 2012 - 01:02 PM

[h4nnib4l]

Sorry, this is what I should have linked to. But I guess it's a moot point, because like Curtis Rutland I missed the XAML-only contraint in the question.

[Skydiver]

tlhIn`toq, on 07 June 2012 - 01:00 PM, said:

So you want this in pure XAML with no code behind to bind the text to?

OK. CHEAT.

Tell the XAML you are binding to a property that doesn't exist, then set your placekeeper text in the FallbackValue of the property

<TextBox Height="154" HorizontalAlignment="Left" Margin="44,40,0,0" Name="textBox1" VerticalAlignment="Top" Width="317" 
                 Text="{Binding Path=dummyproperty, FallbackValue='THis is a bunch of placekeeper text'}"/>

Is there a simple trick to getting it to bind to the real property when the user enters data? (And revert back to the dummy property when the user deletes all the data or fails validation?)

[tlhIn`toq]

Skydiver, on 07 June 2012 - 03:26 PM, said:

Is there a simple trick to getting it to bind to the real property when the user enters data? (And revert back to the dummy property when the user deletes all the data or fails validation?)

Why? Just use the real property with the fallback value: That's what is for, to provide a value in the event there isn't one.

Beyond that its getting fairly complex. I'd do a lot of stuff in C# in the code behind, but that seems to not be acceptable.

[Skydiver]

tlhIn`toq, on 07 June 2012 - 02:52 PM, said:

Skydiver, on 07 June 2012 - 03:26 PM, said:

Is there a simple trick to getting it to bind to the real property when the user enters data? (And revert back to the dummy property when the user deletes all the data or fails validation?)

Why? Just use the real property with the fallback value: That's what is for, to provide a value in the event there isn't one.

Running the app shows the real value rather than the fallback value.

    <StackPanel>
        <TextBox Height="154" HorizontalAlignment="Left" Name="textBox1" VerticalAlignment="Top" Width="317" 
                 Text="{Binding Path=Age, FallbackValue='THis is a bunch of placekeeper text'}"/>
        <TextBox Height="154" HorizontalAlignment="Left" Name="textBox2" VerticalAlignment="Top" Width="317" 
                 Text="{Binding Path=Nickname, FallbackValue='THis is a bunch of placekeeper text'}"/>
    </StackPanel>

    class ViewModel
    {
        public int Age { get; set; }
        public string Nickname { get; set; }
    }

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            this.DataContext = new ViewModel() { Age = -1 };
        }
    }

Output is:


I also tried:

    class ViewModel
    {
        public int? Age { get; set; }
        public string Nickname { get; set; }
    }

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            this.DataContext = new ViewModel();
        }
    }

This just results in two empty TextBoxes.

tlhIn`toq, on 07 June 2012 - 02:52 PM, said:

Beyond that its getting fairly complex. I'd do a lot of stuff in C# in the code behind, but that seems to not be acceptable.

Yeah, for the MVVM Zealots it is unacceptable. They barely accept that the pattern they espouse is actually MVVM+C where sometimes there is no getting around having a controller unless you want to pollute the Model, or the View, or the View Model with concepts that don't really belong there. Just like in the quick and dirty code above, the MainWindow constructor should not have known to instantiate a ViewModel. It should be whatever constructed the MainWindow that should tell it what view model to use. Purist say that a DI framework would take care of this. In that case, isn't the DI framework playing the part of a controller?

This post has been edited by Skydiver: 07 June 2012 - 04:48 PM