I solved this problem by intercepting the date during inserts on the server, setting it to the 10th of the month and year at Noon, and then saving it. This should have solved the problem, but when I use the DatePicker in a Grid (MVC or Web), the cell goes red once I leave it, whether I actually changed the date or not. This is *extremely * confusing to my end users, and given that I am using the MVC grid, subclassing it with my own functionality is not necessarily an option.
The problem lies in how the textbox blur function works, and how it compares values. When it has the following ParseFormats:
.ParseFormats(new[] {"MM/yyyy", "MM yyyy"})
the DateTime object in the browser doesn't have a day to assign, so it assumes the first of the month. When you leave the field, the function simply compares the old value to the new one, sees that the old day (the 10th) is different from the new day (the 1st) and changes the value, which bubbles back to the DataSource, and tells the Grid the data has changed.I believe that the blur function should work in a vastly different way. It should break down the date into its various components, and call the set methods on the old value, instead of just doing a wholesale replacement on the date value. In this example, the function cycle through each component of the date, checking if any of the ParseFormats contain the string representation of that part (d, m, y, etc). If it does, it should call the getXXX method of the old date, and compare it to the getXXX method of the new date. If they are different, it should call setXXX on that component alone, instead of doing a wholesale replacement of the current value of the control.
I know that this would complicate the blur function a bit, but it would more accurately represent how the picker should work, given the already-built-in ability to adjust the depth of the control.
Please let me know if you have any questions or need code to reproduce the issue.
Thanks!
4 Answers, 1 is accepted
Rank 1
Either way, because of this incorrect behavior, I have no way of knowing what the "real" initial value of the control was, at least at the DatePicker level, so I cannot implement my date processing code to be self-contained to the DatePicker. Going to see if I can cancel out the change at the Grid level.
So far, this is really counter-intuitive.
Straight upto your questions:
#1: As you probably already know, the DatePicker will use the format + parseFormats to parse the input value. In the case where the DatePicker is used as a "Month picker" then the day value is not persisted. This is the expected behavior. Could you please elaborate more why you need to use "Month picker", which persists the "day" part of the Date object? I believe that in this case you need to use normal DatePicker. Nevertheless I will log your request to our internal system for further consideration. If other users need such functionality we will schedule it for further investigation.
#2: The "_update" method is called twice because first item is called by the widget itself and the second time it is called by the MVVM (editing of the grid). This is the expected behavior.
I will suggest you use the edit event of the Grid to achieve your goal. Here is a simple demo. In the edit handler we bind the set and change event of the ObservableObject and modfiy newly entered date after change.
I will also ask you to continue our conversation in the support thread to avoid any duplications.
Georgi Krustev
the Telerik team
Rank 1
The described issue is related to DefaultModelBinder (ASP.NET MVC) and it is expected. In order to accomplish your task you will need to define a custom ModelBinder, which will be able to parse the month date string. You can check this blog post for more information about ModelBinders.
Georgi Krustev
Telerik