There is a bug when calculating the scroll container heights in virtualization mode when summaries are shown.
The problem is in infragistics.ui.grid.framework.js method _initializeHeightsInternal. The reference to _footers_v is incorrect, it should be _footer_container.
In addition, the _adjustHeights method of infragistics.ui.grid.summaries.js does not correctly calculate the height of the containers in virtualization mode; changing it to call this.grid._initializeHeights instead of calculating the values directly resolves the problem.
We have discovered these issues because we are working in a size-sensitive application and the grid kept overflowing its container in virtualization mode.
Hi Karl,
Thank you for posting in our forums!
I am able to reproduce this with the sample I have attached with this post and I have a question to help pinpoint the cause of this issue.
Do you still see this behavior when Summaries are disabled and virtualization is enabled? I am seeing a similar behavior in my sample when I remove the Summaries feature.
Looking forward to hearing from you.
Hello Karl,
I have created a support case for you with an ID of CAS-115546-F2N7W0. The matter has been determined to be a development issue and has been logged in our tracking system with ID: 142448.
I will leave this case open and update you with any new information. You can view the status of the development issue connected to this case by going to the “Account” tab on our website, selecting "My Support Activity" and then this support case will be listed there. Then, you may select the "Development Issues" tab to view details of this development issue.
Please let me know if you have any questions.
I've heard back from our developer and he mentions that the avgRowHeight option can be used to set the height of the rows and they will be calculated to fit correctly. You can find more information on this property in our documentation here:
http://help.infragistics.com/jQuery/2013.1/ui.iggrid#options
Please set try setting this option to "35px" and let me know if this helps.
We already have avgRowHeight set to 20px and it does not address the problem.
I don't understand why using the information that I have discovered in the source code is so difficult, especially in blindingly obvious cases like this.
In almost every case I have reported where I indicate what the problem is and the source code modifications I made to fix the problem, the developer pushes back.
This is getting very old and wearing my patience with Infragistics very thin. I am on the verge of recommending that our company move away from Infragistics after 10+ years of use toward a company with more responsive developers and customer service, like Telerik.
I'm sending this issue back to the development team for more research or at least to get a better comment on the original concern you raised with the source code. I will keep you notified of any information I receive back from them.
Hello Jason,
i'd like to ask if there are any news on this.
I'm currently trying to create a (row)virtualized grid, that should fit inside an fixed-sized container. Setting virtualization and a height results in a grid, thats row-container (the html-element the visible rows are stored in) has the height i setted on initialization. But headers, filter-inputs, scrollers, group-elements are also added to the height which causes the overall grid to be much higher than i want it to be.
It looks like the height of elements with ID 'baseGrid_grid_displayContainer' and 'baseGrid_grid_scrollContainer' is not calculated correctly (their height is the inital height i want the whole control to be).
Is this still a bug or am I just doing something wrong?
regards
Lorenz
Awesome, good to hear! If I can be of any other help just let me know.
Thanks a lot, now works like it should. I should have thought about this earlier...
regards Lorenz
thanks for replying. Currently i'm on '13.1.20131.1012', so maybe this version is too old. I'm using the trial-version right now to evaluate the usage of the grid.
I'll replace the files with new versions and report back, thanks for the tip!
Hello Lorenz,
Which build of Ignite UI are you using? The fix for this issue went out in the Jun 27 service release, builds 12.2.20122.2195 and 13.1.20131.2143. If you're using one of those builds or later and still having the issue then we should probably have a support case created to dig in to this a little further.