[Isomorphic]

This code still uses a fieldState changed handler - you need to handle viewState, and not fieldState, if you want to be reliably notified when grouping changes

[levi]

Ok, but this sample illustrates your concern:

field-state would not be expected to change for a grouping change

Changing grouping does fire the FieldStateChanged event.
And also the explicit addGroupByHandler goes wrong.

[Isomorphic]

Thanks, we'll take a look - grouping operations do not, in themselves, directly fire FieldStateChanged, so it must be firing because of the something else (sorting, for instance) - we'll take a look at what combination of properties is causing it.

GroupByHandlers can be cancelled and, as such, are fired before the grouping takes place.

[levi]

Did you see the problem with the grouping event?

I don't really want to use onViewStateChanged because it fires for Selection changes as well. And most of my tests looked like onFieldStateChanged would give me the desired functionality - that is store the appearance of a Grid, so next time the user opens that Grid, I can restore columns, widths, grouping, sorting set by the user.

If that's not the case, is there some way to enhance a ViewStateChangedEvent so we know the reason why it triggered so I can 'cancel' storing the ViewState if the reason is 'selection'? It's not technically wrong, but it sounds overkill to save the ViewState each time the user clicks a record in a grid - especially if we are going to store the viewstate in a database, rather than in the browser's local storage.


cheers,

[Isomorphic]

We've added support for a GroupStateChanged handler which fires after grouping occurs (and before ViewStateChanged fires).
This change will be present in the 9.0 branch in nightly builds dated June 5 and above

Regards
Isomorphic Software