First Look: Editors for WPF

Christoph Brändle

Hello Bill

Looks great, keep in mind that timespan, like

2 days 12 hrs 30 min

is a unavailable but common editor requirement.

Cheers, Christoph

December 31, 2008 at 17:46  

Mike Strobel

I second Christoph's request for custom input format support.  I should be able to provide a custom format string using the standard .NET format syntax and have the editor create the proper input parts *and* generate text blocks for any literals in the format string.  This functionality should essentially be "cost-free" to implement, since you'll need most of it to properly support different locales.

I have one request regarding aesthetics.  Please do not draw focus rectangles, "placeholder" underscores, or the standard blinking caret.  These are outdated UI concepts and rather unpleasing to look at.  I would suggest highlighting the focused input part with a solid background brush.  I think, since the range of input for such an editor is limited (as opposed to a standard TextBox) that an input caret is unnecessary--it can be assumed that inputting a new character will append or clear the content of the focused part (and that hitting backspace or delete will clear a character or the entire part, depending on the context).  Lastly, the editor parts should have fairly intelligent input recognition.  For instance, a Month part that is formatted to display the name of the month should display "June" when I hit the first 'J' (assuming it initially showed "January"), and "June" when I follow up with a 'u'.  If I then hit the up arrow, it change go to "May".  Naturally, this should work in other languages in which the names of the months are spelled differently.

January 3, 2009 at 03:35  

Mike Strobel

Whoops, my text prediction example should have read that hitting 'u' would *keep* "June" selected, and then hitting 'l' would select "July".  Obviously, hitting the up arrow at that point would revert to "June".

January 3, 2009 at 08:37  

Tom Goff (Actipro)

Christoph - Thanks, we do have TimeSpan on our list of types that we'd like to support.

Mike - We do plan on using format strings to specify the input fields and literals. The format string would be one of the "easy-to-use properties" referred to above. Using format strings is pretty natural for types like DateTime, since there are a defined set of format parameters that can be used for the individual parts (year is YYYY, month is MM, etc). For things like TimeSpan, there is no set of format parameters which we could leverage (it only has one format). I think in these cases we will just define our own format parameters.

By default, there wouldn't be a focus rectangle, aside from that one that would be shown around the entire control when entered via the keyboard (e.g. FocusStyle). The image above was just an example to illustrate the different groups/parts.

For the placeholders, there are cases where you can get away without using indicators to show where input is needed (such as with the DateTime parts), but there are other cases where they would be needed. I agree that underscores are not the best prompt character, though. In addition to a configurable prompt character, we have support for prompt geometries mostly done. I've added a note to our TODO list for hiding the prompts altogether.

We can look into a "all or nothing" type entry for the parts. Initially, we were going to keep the caret and allow it to be moved between parts. With what you described, the user would need to re-enter the entire contents of the part. For most types (e.g. DateTime), this probably isn't an issue.

Your thoughts on the "intelligent input recognition" are identical to how we planned on implementing it. One noted exception is when typing secondary letters. For example, if I type 'J' then June would be selected. If I type 'J' again, then (assuming there is no "JJ*" entry) July would be selected. This would cycle around to the beginning of the list also, so January would be selected on a third 'J'.

January 3, 2009 at 14:58