I think it would be more helpful if the Kendo UI Documentation is structured similarly to other Telerik Product Documentations where each control (widget) provides a complete overview, visual structure, getting started, and a how-to section (which I'm guessing is a compiled list of frequently asked scenarios).  I'm struggling/spending too much time having to research how to do (what should be) the simplest things with these widgets.  It seems that' I'm having to revert to the Demo's and online threads more than the documentation.. that' can't be good!

Currently for the Window and Tooltip controls (possibly others, but those are the ones that I'm working with), the Height and Width properties are both integer properties which set the height and width in pixels.  I would like the ability to be able to enter Height and Width in 'em' units, much like can be done with the grid column widths. 

Hi Telerik Team:

I have some suggestions

1.- Add Scafolding for TreeList UI for ASP.NET MVC 
2.- Add Cell Edit with template for TreeList UI for ASP.NET MVC

Thanks

This is in reference to the following forum post:

https://www.telerik.com/forums/helper-for-textbox#lpm4Co4Zy0-PHGzJD_E2mA

For consistency in the MVC product, it would be a good idea to expose built-in events such as the "change" event for the generic Html.Kendo().TextBox helper. This is provided for other controls like the DateTimePicker and even NumericTextBox (https://demos.telerik.com/aspnet-mvc/numerictextbox/events) but not for TextBox.

As mentioned in my post, this is not an insurmountable problem. I can do what I need by diving "down" into jQuery, but it would be nice to be consistent.

When using QueryableExtensions.ToDataSourceResult() from Telerik MVC, SQL following gets produced:

.. FROM [RMP].[V_UC_EQUIPMENT_LOG2_LOCALIZATION] WHERE ([Extent1].[LOG_TIME] >= convert(DateTimeOffset, ''2019-03-05 23:00:00.0000000 +00:00'', 121)) AND ([Extent1].[LOG_CLASS_ID] IN (78,7,18,30,19,16,17))

When we filter manually in code with linq, e. g.

..  table.Where(e => e.T_EquiID == 234234) ...

the linq provider produces a parameterized query as follows:

AND (@p__linq__0 = [Extent1].[T_EquiID])...

When using a parameterized query, Sql Server can reuse the execution plan much better saving compile time, which is in our case sometimes a big issue.

Please tell us, why can QueryExtensions do produce parameterized queries.