Tweets by @Actipro
Please take some time to learn more about us and our product offerings.
In addition to our work on SyntaxEditor for WPF, we are also actively building Editors for WPF. We previously announced that this product is going to include a parts-based editor, which will simplify data entry for various data types such as DateTime. We have completed most of the core functionality needed for building and presenting the various parts. We have also completed much of the work needed for a DateTime-specific implementation.
A DateTimeEditBox with a focus rectangle around the date group
In the image above, there are two groups (one for the Date and one for the Time) seperated by the literal text "at" inside the DateTimeEditBox. Both groups include several parts, such as month, day, and year. Each part can then present, modify, or validate it's data independently. This allows the day part to be restricted to 28/29, 30, or 31 depending on the current month. Additionally, this allows the user to update the month and have the day automatically corrected. For example, if the current date is "1/31/2009" and the month is changed to 2, then the current date would be updated to "2/28/2009".
By default, the DateTimeEditBox will build and configure the groups/parts based on easy-to-use properties. More complex setups can be accomplished as needed by using the groups/parts directly in a custom parts-editor. Additionally, since each group/part is ultimately a WPF control, you can style them like any other control. This gives you more control over the look and feel of the groups/parts.
We intend to provide specific implementations of the parts-based editor for several .Net types, including DateTime, IPAddress, Color, Size, and more. If you would like to see a parts-based editor for a specific .NET type, please let us know now. Of course, you can always leverage the infrastructure we are building for any custom types you may have.
We’ll post some more screenshots in the coming weeks as progress is made on specific implementations.
December 31, 2008 at 17:46
Hello BillLooks great, keep in mind that timespan, like2 days 12 hrs 30 minis a unavailable but common editor requirement.Cheers, Christoph
January 3, 2009 at 03:35
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 08:37
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 14:58
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'.
Tom Goff (Actipro)