I am in the process of converting from UltraWebGrid to the most current version of the WebDataGrid.
The version we are using is: 14.1.20141.2150
Because the WebDataGrid does not default to at least the width of the header, we have to dynamically set the width of the column. We dynamically set the width of the column based on the width of the header text and the width of the generated column. We do this on the grid's client side Initialize event.
One of our grids has a large number of columns, 50+. The method we use for dynamically setting the widths is performing extremely slow for this grid. I have determined that it is due to the set_width() method taking a little over a second to run every time it is called.
I have stripped out a basic representation of the large grid and have attached it in the sample below. In the sample you will see that it will take anywhere from 45 seconds to a whole minute for the column widths to calculate. Although this is a large grid, a minute long load overhead is unacceptable for our requirements.
Are there any more efficient methods for setting the width of the column dynamically on the client side?
The set_width() method appears to recalculate the scroll bar and all the other columns of the grid. Is there a method to skip these additional calculations and just update the width of the columns? Specifically is there a set_width method that bypasses the OnResizing event?
Thanks,
Mason
Hello,
Thank you for contacting us and for providing this sample.
I have managed to run it and observe the issue. I see that you use Radoslav's article regarding "Autosizing columns in WebDataGrid". After further investigation I wanted to let you know that it is not recommended to have 100+ column (as it is in the sample), my suggestion is to separate them as much as possible for example in 3 grids nested in WebTab or something like that. You are right about the set_width method that perform a lot of other operations like scroll calculating etc.
I can recommend you also to try to resize them server size on InitializeRow grid event.
Another thing that I can suggest you is to log a Product Idea at http://ideas.infragistics.com. In IgniteUI we have column virtualization and you can name the PI like it. The Product Ideas site allows you to suggest new product features, new functionalities in existing products and controls, and even request new controls and products altogether. Members of the Infragistics Community then vote for the features and suggestions they want to see added to the products, resulting in the most popular features bubbling up to the top. When planning new releases, our Product Management team will look at the most popular features and use your feedback to prioritize upcoming work.
Related references:
http://www.infragistics.com/community/forums/t/35550.aspx
If I may be of further assistance please contact me.
Thank you for the response.
I solved my issue by disabling the dynamic width calculation for this specific large grid. I then manually set all the widths of the columns. This eliminated the calls to set_width() for that specific grid.
I agree with 50+ tabs being a bit large but breaking the grid into web tabs and essentially completely reworking the entire page is out of scope for my project.
Thanks,Mason
Hello Mason,
I am glad to hear that you've managed to resolve this performance issue.
Thank you for using our controls!
If I may be of further assistance, do not hesitate to contact me.
Actually I could use some more help. I have opened another post:
http://www.infragistics.com/community/forums/t/91505.aspx
Hi Mason
I am also facing the same issue , can you please help and let me know how disabling the dynamic width calculation?
Regards
Rakesh