DateTimeEditBox Upgrade from v2015 to v2019 - format not enforced

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".

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.

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?

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?

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?

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.