We're rebuilding our application using WPF and Infragistics components. We have a tab control, and multiple tabs. Most tabs contain a XamDataGrid.
Tabs that contain a XamDataGrid are very slow to load. A few tabs contain a XamTileManager with multiple XamDataGrids. These are very slow.
XamDataGrids in seperate views do not cause this problem for us.
Note: I'm not referring to the initial slowness caused by loading dlls. The tabs are still slow after opening and closing multiple times.
After testing and eliminating, we found that setting AllowRecordFiltering to false speeds up the loading of the tab by a factor of 2-3.
We want filtering. Is there a workaround for this problem?
I have attached a demo-project showing the problem. Loading the view (with 6 xamdatagrids in a xamtilemanager) averages about 1100 ms on my machine.
Setting AllowRecordFiltering to false causes this to drop to 450 ms. This seems like a bug, but perhaps there is a solution?
Hello Freek,
I have been investigating into this issue that you are referring to, and I have reproduced it. After profiling the sample project that you have provided with and without the AllowRecordFiltering setting, I am seeing that most of the time appears to be spent verifying the cells that are in view for each of the XamDataGrid elements, whereas this code-path is hardly there when the AllowRecordFiltering setting is set to false. This is likely due to the FilterRecord being created for each grid, and the FilterCellValuePresenter creation for each filter cell that comes into view, although I would not expect it to take essentially double the time as when the XamDataGrid does not have filtering.
I am going to continue to investigate into this issue with our development team, and I hope to have more information for you on this matter soon.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate Developer
I have investigated this issue a bit further, and I am able to reproduce the behavior in which the XamDataGrid does appear to take a bit more time when loading when AllowRecordFiltering is set to true versus when it is set to false. At the moment, I have not been able to really find a workaround to this, outside of perhaps having filtering be disabled when the view loads, and then having a toggle button or checkbox that allows or disallows the filtering on your six XamDataGrid elements. It is also worth noting that when toggling the AllowRecordFiltering property, even when the grids are already in view, this operation does appear to take some time.
I have asked our engineering staff to examine this a bit further to see if it is expected as there are six XamDataGrids loading at the same time, and as such the FilterRecord's presenter will need to be initialized, or if this should be considered more of a bug in the XamDataGrid. To ensure it receives attention, I have logged this issue in our internal tracking system with a development ID of 244036. I have also created a private support case so that you can track this issue. This case has an ID of CAS-187869-S9F2P3 and you can access it here: https://www.infragistics.com/my-account/support-activity. I will be sending the initial update to this support case shortly with further information.
Hallo Andrew,
Thanks for the response and quick uptake.
Happy you could reproduce the issue. Hopefully a solution can be found.
Till that time we might use the suggestion to disable filtering unless the user checks a box.
Kind greetings,
Freek
Hi Andrew,
Do you have any update on the described issue?
Regards,
David
Hello djaspers,
At the moment, development issue 244036 is still being reviewed by our development teams at the head of the XamDataGrid control, and development has not started on it yet. I would expect that development should start on this issue soon.
I've read your message to the support case, and understand that it's due to the amount of elements in the filter record's visual tree.
Just wanted to confirm that the problem remains with the newest Infragistics libraries (17.2.20172.2029). Before this we were using two year old libraries. We didn't expect an improvement, but just wanted to let you know.