DateTimeEditBox Upgrade from v2015 to v2019 - format not enforced

Editors for WPF Forum

Posted 5 months ago by Brad Salmon
Version: 19.1.0684
Avatar

I'm upgrading from v2015 to v2019. In v2015 we set the DateTimeEditBox.Format to our desired format such as "MM/dd/yyyy". At runtime, the control displayed the date in that format and the control always displayed the "/"'s and user could only enter valid #'s in the parts.

After upgrading to v2019, we are still setting the Format to "MM/dd/yyyy" but the user can type anything (including letters) in the control and are also forced to enter the "/"'s when typing the date.

1) Is there a way to prevent the entry of invalid characters (i.e. prevent letters when the format specifies only numbers are allowed)?

2) Is there a way to configure the control so the user doesn't have to enter the "/"'s to get a valid date entered?

Comments (6)

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Brad,

The changes we made in the newer version were a little about trade-offs.  The old version had a very complex internal design that used multiple sub-controls and was relatively "heavy" in terms of elements.  This made them more memory intensive and took user interfaces that made use of many editors (like PropertyGrid) much longer to load.  On top of that, it was very inflexible on how dates had to be entered.

The newer version makes use of a single TextBox control in the edit box's template.  It's far more lightweight in terms of memory/elements, uses many fewer bindings, and has simpler logic on the inside.  Everything runs very fast with the newer design.  The downside of the change is that some of the prompting isn't available that was before.

Regarding your questions...

1) That is something we may look into in the future.  In the meantime, you might be able to look for the TextBox control within the template (such as in an OnApplyTemplate override, and look for the part named "PART_TextBox").  Then hook into its events to block certain input.

2)  A quick note... if you are doing dates only, use DateEditBox instead of DateTimeEditBox.  It's pretty flexible in how input is accepted.  You could enter dates in common formats like yyyy-MM-dd if you wish.  All the processing happens in the protected virtual DateEditBox.TryConvertFromString method, which uses calls like DateTime.TryParseExact, DateTime.TryParse, etc.  We also have fallback logic so if you don't type a "/", and enter "02042020", it will parse that as "02/04/2020".  So it should already be supporting that.  It just won't prompt the "/" characters until the final value is committed.  By overriding TryConvertFromString, you could also support things like "today".


Actipro Software Support

Posted 5 months ago by Brad Salmon
Avatar

Thanks for the background. I certainly appreciate the improved performance. I will take a look a the DateEditBox, that sounds like it would probably work well for us since most of the time we only need a Date.

Posted 5 months ago by Brad Salmon
Avatar

I'm trying to use the DateEditBox control, but it isn't working the way you said it would. I have a field with the Format set to "MM/dd/yyyy". I type "10311968" into the field and tab out. The control is then empty. I added an override to the TryConvertFromString method on the control. I see the "textToConvert" is "10311968" and canCoerce is false. Calling base.TryConvertFromString returns false. Is there some property or something else I need to do for the "fallback logic" you mentioned from working and treating the entered value as 10/31/1968?

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Brad,

When I load up our DateEditBox QuickStart and scroll down to the first Gallery example with placeholder text, I paste "10311968" in there and tab out and it accepts the value ok for me.  This is in v2019.1 build 684.  I picked that example since it's a plain DateEditBox without any special properties set.  Do you see the same?


Actipro Software Support

Posted 5 months ago by Brad Salmon
Avatar

Yes, when I use that QuickStart example it does behave has you describe. However, on that QuickStart view in the "Options" section if I specify the Format as "Custom (MM/dd/yyyy)" and enter 10311968 in the edit box at the top it doesn't work. If I set the Format to "Short date", however, it does work.

So does the "fall back" logic only work if specifying a .Net format code?

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Brad,

That is correct, our delimiter-less logic only kicks in for the short date ("d") format.  We do that so that we know the format is for a date (and not a time, which has its own logic).

I think it would make sense to also support some common custom formats like "MM/dd/yyyy" so they can have this feature too.  We'll add that for the next maintenance release.


Actipro Software Support

The latest build of this product (v2019.1 build 0685) was released 4 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.