The behavior of the TcxDateEdit control changed sometime in the last couple of builds.
If you have an event handler on TcxDateEdit.Properties.OnChange you can see this event gets triggered by simply tabbing into and out of the control. Previously this was not the case--the event only fired when date value was changed.
Please review and run the attached sample project.
As you tab between the controls, you can see that each time the date edit gets and loses focus the event is triggered (a message is appended to the list box).
I think this might have something to do with the regional settings. I normally use a short date format of 'M/d/yyyy'. Using this format, the textvalue of the control changes from '1/1/2012' (Jan 1, 2012) to '01/01/2012' when the dateedit gets focus. And then it changes back to '1/1/2012' when it loses focus. In this test, the OnChange event fires twice (once on getfocus, once on losefocus).
I repeated this test with the date format regional setting set to 'MM/dd/yyyy'. In this case, the OnChange event DOES NOT fire on get/lose focus.
So it looks like something is getting messed up when the inner edit control is synchronizing.
This behavior changed sometime in the last 2 or 3 builds. I hope the current behavior is not intended since it makes it difficult to know when a date value gets changed. It would seem odd that the behavior of an event would be dependent on a regional setting.
Thanks in advance for your help...
Thank you for your message. This behavior is by design, and it is caused by the fact that the display value is changed when the TcxDateEdit receives/loses focus. Please review the Maskedit triggers OnChange event when it receives the focus report for more detailed information about this behavior.
This is NOT GOOD!
We have been using the OnChange event handler on the TcxDateEdit control for many, many years and now all of a sudden its behavior changes! I'm sorry but that is a very, very, very bad answer. You are telling me that we have to go through hundreds of forms and re-engineer how we detect when an edit control changes! I'm sorry but that is NUTS.
Who would ever suspect that an event fires or doesn't fire based on your regional settings.
We view this as a very serious issue due to the amount of work and retesting that is required on our part.
Please escalate this issue to the appropriate decision makers. I'm not sure what it will take to maintain the previous behavior. Maybe a new property, something like "OnChangeBehavior". The default could be "logical" or "kooky behavior some doofus at DevExpress thinks makes more sense". (just kidding. You guys normally do a stellar job but you screwed the pooch this one...sorry)
We are concerned that you have had such a bad experience with our controls. We are always here to help you in adapting our controls to serve your needs.
I am forwarding this issue to our developers for further processing. We will get back to you once we have any results or need additional information. Thank you for your patience.
After digging into this a some more I think I understand a little about what's going on.
(with the regional settings for dates set to M/d/yyyy)
In build #56 the TcxDateEdit control does NOT change the display text when the control gets focus. That is, with a date value of Jan 16, 2012, the control displays '1/16/2012' both when the control HAS focus as well as when it DOES NOT have focus.
However, in build # 20110203 the display value is '01/16/2012' when the control has focus. And when it loses focus, the displayed value reverts back to '1/16/2012'. Based on the statement:
"For text editors, the OnChange event occurs when changing the display value provided by the TcxCustomEdit.Text property and is fired by the TcxCustomEdit.DoOnChange virtual method."
I think that is what's causing the OnChange event to be fired.
Anyway, it still doesn't make sense why an event named 'OnChange' would fire when nothing has really changed. Even the control's property 'ModifiedAfterEnter' reports False in the OnChange event. The thought that an OnChange event would fire when a user simple tabs through a control is counterintuitive. I am unable to imagine a scenario where this is the desired behavior.
I want to reiterate my encouragement to find a solution so that the behavior that has existed for a number of years doesn't change. In its current state, this control makes testing a nightmare. If your regional settings display a 2 digit year you don't see the funky behavior. Likewise, if you're testing with a date in October, November or December (i.e. months with 2 digits), you likely won't see anything odd.