Hi all,
I have a big issue with the UltraWinGrid. Our application has a grid, which the user can add a column with a formula too. They can also filter using the row-filter, and group using the Group-By box.
Grouping and filtering works fine when there are no columns in the grid that have a formula associated with it. The user can also group on any column when a formula column is present, quite happily.
If the grid includes a formula column, which is filtered on, and then attempts to group by a column, the application appears to lock up. I say appears because it takes an incredibly long time (so much so that we have never seen it complete the grouping - and we've left it a good half hour). The application appears to still be running, however. On closer inspection, it appears to be trying to ensure all the cells of the formula column have been calculated before making the grouping (which makes sense), but it seems to be getting itself in a right twist!
The issue also occurs if the user groups by a column first, then adds a formula column (all is okay so far), and then types a filter into the formula column. When attempting to filter (by typing or by selecting a value from the list), the same thing happens - locks up the UI thread and effectively dies...
This issue has only been noticeable since we've upgraded to WinForms 2010.3. We have the latest hotfix, 2015. This issue is apparent with or without the hotfix.
This is a real big issue for us and I can't see anything we've done that would cause this, as it's locking up outside of our code!
We've also noticed an issue recently where if the user filters on a column for the first time when the grid is first shown, the filtering looks like it's being optimised or something for the visible rows. When the user scrolls down the page, the number of rows that have been filtered out changes and the user can see this happen. The more they scroll up and down, the more it changes!! Very strange behaviour... Even more strangely, the grid snaps out of this behaviour if the user applies a sort, before or after filtering! The behaviour only occurs if the user TYPES a filter into the row filter for a column and no sorting has been applied to the grid.
Could any one shed some light on this issue, please! If anyone needs any more info, please ask.
Cheers,
Richard
I've tried to reproduce this issue on an older version of our application that uses WinForms 2010.1 (build 1007), and I cannot reproduce it. There haven't been any changes to the grid since this version to my knowledge, so I'm guessing this is an issue with one of the recent releases(?)...
Hi Richard,
The interaction between formulas, grouping, sorting, and filtering is pretty complex and we have made a number of bug fixes in this area over the past year. We try hard to make sure those things don't happen, but it's never 100% certain, so it's possible that one of those fixes broke something that is causing a problem in your application.
Unfortunately, there's not much I can think to tell you without being able to see the problem occur. Are you able to reproduce the lock-up in a small sample project and post it here? Perhaps you could copy your application and narrow it down to a single form, or try to reproduce the issue using one of the samples in the WinGrid Samples Explorer.
Richard said:We've also noticed an issue recently where if the user filters on a column for the first time when the grid is first shown, the filtering looks like it's being optimised or something for the visible rows. When the user scrolls down the page, the number of rows that have been filtered out changes and the user can see this happen. The more they scroll up and down, the more it changes!! Very strange behaviour... Even more strangely, the grid snaps out of this behaviour if the user applies a sort, before or after filtering! The behaviour only occurs if the user TYPES a filter into the row filter for a column and no sorting has been applied to the grid.
There is no filtering optimization for visible rows. The filtering is applied asynchronously, but it always has been - nothing has changed there. And it happens when the grid paints the first time, not as the user scrolls. So I have no explanation for the behavior you are describing here. Is it possible that this is an optimization in your own code?
Hi Mike,
Thanks for all the information. As it's such a specific case in which the issue occurs, and there is a work-around for the user, it's not a high issue. When I have the time, I'll try and reproduce it in an sample application.
Thanks for you help!