ASP.NET MVC Model Binding and the Kendo UI Trigger method.

The current project that I am working on is an ASP.NET MVC application that makes use of Telerik Kendo UI controls. This is my first time to use this suite of controls and I am very pleased with the features/functionality that Telerik has implemented with Kendo UI. Telerik also has very nice documentation to refer to and an a great forum to post questions on (moderators typically respond very quickly).

That being said, I am still in the process of learning the ins and outs of all the Kendo UI controls. A recent issue that I ran into dealt with a null value appearing after model binding of an AJAX request.

In my situation, I was using a Kendo ListView control. Inside the editor template, there were multiple controls, one of which was a Kendo Drop Down List control. The requirements for my screen were such that depending on the user answer for another control, I needed to dynamically change the value of the Drop Down List control and disable is so that the user could no longer modify the value. This was easily done via jQuery using the following two lines of code:“kendoDropDownList”).value(“Flat”);“kendoDropDownList”).enable(false);

However, when clicking the “save” button on the ListView control, and after stopping on a breakpoint on the Action method inside of my controller class, I found that model binding had correctly sent me all the control values in the ListView except for the Drop Down List that I dynamically changed. 

At first, I surmised that model binding may not be working correctly due to disabling the control. After commenting out this line and running the test again, the value of the Drop Down List wall still not being correctly set via model binding. Model binding worked perfectly when I did not dynamically supply a value via jQuery. 

At this point I searched though the Kendo UI web site and also opened a ticket on the Kendo MVC forums. That forum entry is here:

It turns out that dynamically changing a value for Kendo Controls via jQuery does not automatically trigger the “change” event to fire. The missing piece is that after changing the value of my Drop Down List via the line above, I needed to call the “change” event for the control manually via the Kendo UI trigger method. For example:“kendoDropDownList”).value(“Flat”);“kendoDropDownList”).trigger(“change”);“kendoDropDownList”).enable(false);

Once I added this one line, model binding during the AJAX request to “save” the ListVIew item worked perfectly for all the controls within the ListView.

Hope you find this information useful.


Code Coverage and Windows Workflow Foundation

In the current ASP.NET MVC project that I am working on, we are using Windows Workflow Foundation to handle both the online and offline processing of invoices. We are also using the unit testing framework that is built-in to Visual Studio. One of the nice tools that is part of the unit testing framework is the Code Coverage Analyzer. It’s purpose is to identify the percentage of code that is being tested by your entire set of unit tests. After running the analyzer you can drill down into each of you projects to see what code is being tested and what code is not. The analyzer color codes the lines to make this easy to see. It also calculates the overall coverage percent of your entire solution and for each of your projects so that you can easily determine where “holes” in your unit test coverage are occurring. The overall coverage percent is shown below on the first line under the heading “Covered (% Blocks)”. For more details on this number and the rest of the numbers, please see the link above.


Out of the box, the Code Coverage Analyzer will “analyze” all the projects that are part of your solution. Unfortunately this also includes the project that contains all your unit tests. Because this happens, the overall coverage percent of you entire solution may not be what you expect. In our case, we do not want the analyzer to include the unit test code as part of its overall calculation.

The good news is that is an easy way to inform the analyzer of code that you want to ignore. You can add the “ExcludeFromCodeCoverage” attribute to the class definition and the analyzer will skip this class when it executes (The downside is that you will have to apply this to all classes in your unit test project). For example:

/// <summary>
/// Unit tests for the LineItemTaxRepository class.
/// </summary>
public class LineItemTaxRepositoryTests


Don’t forget that you also include a “using” statement for the “System.Diagnostics.CodeAnalysis” namespace in order to use this annotation.

OK, what does all this have to do with Windows Workflow Foundation? Good question. If you are using Windows Workflow Foundation and eXtensible Application Markup Language (XAML) files and you run the Code Coverage Analyzer, you will quickly realize that the code coverage analyzer includes all the code that is generated under the covers by the XAML files and again this will skew the code coverage percent for all project(s) the contain XAML files. It also will skew the overall code coverage percent of the entire solution.

At first, it may appear that there is no way around this issue since the code in question is automatically generated during compilation and you as the developer do not have direct access to the source code. However, there also is a way to use the “ExcludeFromCodeCoverage” attribute.

The code generated from the XAML files is created as a partial class. Thus, the solution is to create a separate partial class with the same name as the XAML file, and apply the “ExcludeFromCodeCoverage” attribute to your new partial class. Bingo, no more skewed code coverage percentages.

So for example, suppose I had a XAML file called “LineItems.xaml”. I would then create a partial class with the following definition:

/// <summary>
/// Partial class used only to signal to the Code Coverage Analyzer to ignore Windows Workflow Foundation generated code.
/// </summary>
public partial class LineItems  { }

Hope you found this information helpful. There are probably other solutions to this issue but during my searches on this topic, I did not find a way to avoid this problem.