Sorry, but my sample project had a couple of bugs. Attached is a revised version.

In order to fully implement the "Html.Kendo().DropDownListFor(m => m.OrderId)" functionality, uncomment the row in HomeController.GetDropDownListValue(). You will notice a change of behaviour when tabbing, which I don't quite understand. It seems to me though that getting the value mapper functioning in the right way is the key to the problem.

Hi Veselin, the thing is, if you understand what's going on then there must be some way to reproduce the behaviour. As I have already mentioned, I believe there is a race condition happening between my jQuery code and the value mapper function. 

With this is mind, I have attached an updated project with some changes:

1. In site.js, I have added a one second delay to the function ValueMapper(), although I'm not sure this will help. Perhaps you can come up with a better idea.

2. Just to clarify your point about the lack of validation errors, it is important to understand what I have been saying here. In this project, the value of the dropdown list was NEVER NULL, meaning validation would never fail. My point was about what was happening in the change event, not validation.

Having said that, I have provided an option to test validation. In Index.html, change the code "Html.Kendo().DropDown()" to "Html.Kendo().DropDownListFor(m => m.OrderId)" and uncomment the validator initialisation. The dropdownlist will initially be set to null and fail validation only if the behaviour can be reproduced.

3. If all else fails, try setting the control's AutoBind property to false, which changes behaviour slightly.

Hi Veselin, there are actually two things you are missing. The most important thing was:

The previous value is returned in these cases, which is why we are getting validation errors when the previous value is null.

In this sample project the previous value is never null so the validation doesn't fail, but this behaviour is secondary to what is happening. Please try it again, except this time, please take note of what I said about the alert box:

1. Type "32".

2. Press Tab or Enter.

3. The alert box will report "Value changed to 1".

Now reload the page and do the following:

1. Type "32".

2. Select the value with the mouse.

3. The alert box will report "Value changed to 32".

Do you understand what I'm saying? Using the Tab or Enter key results in the OLD VALUE being returned.

As I have mentioned previously, In spite of this fact, if validateOnBlur is set to FALSE, the CORRECT VALUE is returned in the model when the form is submitted.

Hi Veselin, I have attached a sample project that reproduces the behaviour.

To reproduce it, select the dropdown list and enter a value outside the page size of 20 (say 32), then press the enter or tab key. An alert will then display the value. The trick is to not use the mouse except for setting the focus on the widget.

Having created this project, I now see what's happening. The previous value is returned in these cases, which is why we are getting validation errors when the previous value is null. But the thing is, the change event is fired every time, which is what makes the alert box display.

Hi Veselin, I should have been clearer with my question about syntax. While I understand the difference between wrapper and element, I wanted to know how each implementation may differ in this context. After some further testing I found that my method using $(that.wrapper) works, while using that.element doesn't.

I'm not sure what you're saying about widget.value(). How do I set it? Since the purpose of my code is to select a value through keyboard events, the value isn't available until the events are completed, and I know for a fact that the change event is being fired after the keydown event is processed. Surely this must indicate that the widget has accepted the selection that was made?

In any case, it doesn't make sense that validateOnBlur=false works without any validation failures. In other words, setting it to true results in a validation failure, while setting it to false results in a validation success when the form is submitted. What this tells me is that there is a race condition happening during the validateOnBlur process that is producing a false negative. How do I ensure the value has been set before the validation takes place?

Hi Veselin, since my jQuery code is triggering the keydown event, the widget's change event is subsequently triggered anyway. I tested and confirmed that your method doesn't work.

I'm not even sure that your method is the correct way to achieve this. Since the keydown event is jQuery's first key event, wouldn't it precede the change event, in which case the selection is sure to be made prior to the change event being triggered? Or does this not matter?

Also, I see that you are using the syntax "that.element", whereas I am using "$(that.wrapper)". Are there any differences between the two?

After doing some further investigation, I may have discovered what's happening here. What I initially thought was inconsistent behaviour seems to be down to the use of custom datasources of type "aspnetmvc-ajax" with value mapping for large lists. Is there a method I can employ to trigger the value mapping, or is there some other way to do it?