[Solved] grouping issues

[Euvic]

Hi,
We use GridView (2012.3 1129) quiet extensively, we utilize many of its features and we have implemented lots of custom functionality. However, we have some issues with grouping. 

Firstly, we have to manually change records in the grid’s source list. What I mean is we have implemented functionality that helps us modify multiple rows at once using some dialog windows, so we edit source list to perform requested changes.

Secondly, we want the grid not to move its records after edition. We don't like that records are moved to other group when we change a value in column which grid is grouped by and we definitely don't like that records are moved within a group when we change a value in column which grid is not grouped by.

In our first approach we weren't changing record reference in source list of grid, we were copying its properties one by one. So instead of:

source[index] = editedRecord

we had:

source[index].PropertyA = editedRecord.PropertyA;
source[index].PropertyB = editedRecord.PropertyB;

It worked fine until we grouped the grid. When the grid is grouped by some column and we modify properties of some record in this way (including value of the column which data is grouped by), the record is no longer selectable. Moreover, sometimes when we try to select multiple cells including these unselectable, we select many other cells of which we often don't know, because the rest of selected cells are in other groups, which are collapsed. This was unacceptable.

Next thing we tried was to add grid.Rebind() after every edition. We thought that with rebind and our version of editing records which is shown above, grid will behave like without our version of editing and then we will be working on resolving our unwanted moving records issue. It didn't - after every rebind, grid scrolled up to the top. We thought we can save the value of scrollbar and set it after rebind. We discovered that setting value of scrollbar changes the position of scrollbar and scrollbar only - data in grid stay in the same position. We don't know if it's some issue because we didn't try to fix it, because even setting value of scrollbar did work only when grid wasn't grouped. When it was, settings value of scrollbar worked only when before rebind scrollbar was on the top. When we dragged it down, changed some records, performed rebind and set value of scrollbar to value saved before rebind, scrollbar got back to the top.

So we got back to simple changing of edited records references in source list - like without our workaround for not sorting and not grouping records after edition. And we tried to provide custom sorting to avoid reordering records caused by unstable default algorithm. We did it exactly like this: http://www.telerik.com/help/silverlight/gridview-sorting-custom.html. And it worked until we grouped our grid. After every sorting all groups are collapsing. This can be annoying.

Additionally, we had one more issue, which I can’t reproduce right now. After changing value in column which the grid is not grouped by, new group appeared (with the same header like the one with the row we were editing) and edited row was moved to this new group.

Is there a simple way to make the gridview not to sort, not to group, not to collapse, not to scroll up etc. after modifying source list in code?

Thanks in advance.

[Maya]

Hello Jakub,

Each behavior that you describe as unwanted is actually the expected one and how the users of RadGridView anticipate it to be. Once you group the grid, it will investigate all its items and the values of the properties it is grouped by and perform the required logic so that each group contains only items with the corresponding value.    

Kind regards,
Maya
the Telerik team

[Euvic]

Thank you for your reply.
I know that described behavior is generally expected, but not for us. When we manually edit rows, like 50 of them one by one and rows are moved and we encounter rows we already processed or we want to simply take a glance to be sure that row is processed properly and we can't do this - this can be annoying. We just want to know if there is some workaround you can think of.