The selector area of the dragging to select automatically goes all the way to the left; could that be changed so that the area shows up only from where the user clicked to where the cursor goes, like Windows Explorer? (see attached image)
When I said starting from "white space", I meant the space between the items and the pager. Please refer to attached screenshot. As you can see, we're keeping the grid the full height of the web page. if there are less items, there is a white gap between the row items and the pager. If starting the dragging to select from the white space, no items will get selected. Can we add this feature to RadGrid?
There are TypeScript definitions for enabling intellisense
In a non Telerik 3rd-party tool we can export to Excel, and groups that have been defined will be rendered with group buttons in Excel that can be expanded and collapsed in the Excel spreadsheet. With Telerik when we export a RadGrid that has a user-defined group, there are no grouping expand/collapse buttons in the generated Excel spreadsheet. Related Telerik Support ID: 758667 Thanks.
Hi, in Radgrid header context menu filter section would be nice the possibility to add field to filter and change the logical operator (AND / OR ). Best Regards
For the time being the following workaround can be used: CSS: <style> .RadGrid_Default .RadButton_Simple input { border: 0 none; } </style> ASPX: <telerik:RadGrid ID="RadGrid1" runat="server"> <MasterTableView> <Columns> <telerik:GridTemplateColumn UniqueName="EditColumn" AllowFiltering="false"> <HeaderStyle Width="70px" /> <ItemTemplate> <telerik:RadButton ID="rbEdit" runat="server" Text="Select" Skin="Simple" AutoPostBack="false"> </telerik:RadButton> </ItemTemplate> </telerik:GridTemplateColumn> </Columns> </MasterTableView> </telerik:RadGrid> where Simple is the name of the used Skin.
Since Q3 a change in the client-side binding of the GridTemplateColumn has been introduced. The column no longer automatically populates controls in the ItemTemplate. The change is result of an optimization in code regarding the virtualization and batch editing features of the grid. The new behavior is far more optimized and ensures much faster and robust operation of the control in various cases of client-side binding.
If I'm to believe the Telerik agent in this forum thread... http://www.telerik.com/community/forums/reply-thread.aspx?messageId=0&threadId=750553 then presenting users WITHTEXTTHATLOOKSLIKETHIS (as is done by default in Metro Skin Grid Filter Menu) is a "design" feature. I happen to believe that menu items ought to be readable by human users and not appear like they are the result of some sort of keyboard malfunction... at least by default. If some "designer" out there feels the need to present their users with ABSURDTEXTFORMATTING, then it is they that should be required to implement some sort of hack, not the rest of us. This was a horrible design decision made by someone at Telerik, and the fact that I am required to appeal to other developers who have better things to do with their time in order to get Telerik to see the absurdity of this design and fix it is most troubling.