[Isomorphic]

This issue is currently under investigation. We'll follow up soon

Regards
Isomorphic Software

[Isomorphic]

Hi Pat,
We've been looked at this issue again, and think it's worth giving you an update of where things stand.

To summarize the behavior here:

1) When you have a grouped grid, and an edit changes a record's group-field value (such that it must move to a new group), a full regroup occurs.

This is known and expected. At some point in the future we may come up with a way to just make minimal changes to the tree to reflect the new grouping, but it's not something we'd be implementing as a bug fix or small feature to back-port.

2) When an update occurs such that a record no longer matches the current filter criteria, and so is dropped from the ResultSet cache, we also do a full regroup.

Again - in the future we may come up with a more efficient way to only rebuild the part of the tree which needs it, but this isn't a trivial change we can quickly apply and backport.

3) When an update occurs on another field in most cases no regroup is required. You can try this with your example by grouping by the "Content" field, and then selecting a record and hitting the button to modify the Status. It updates inline, as expected.

4) When an update occurs on the sort field, we also regroup. This is somewhat unexpected and we are looking at whether we can avoid this behavior. More information on that soon.

5) When we do a full regroup, the standard "reselectOnUpdate" type behavior isn't re-selecting the record. We're also looking at whether this is something we can achieve.

Regards
Isomorphic Software

Can you clarify what the expected behavior is when adding a new record or having a record get added (instead of dropped) by filtering? You didn't explicitly mention these two cases.

[Isomorphic]

Currently if a record is added or removed from the data-set, either due to an update operation which changes whether or not it matches criteria, or due to an add or remove operation, the tree will regroup.

If an update occurs such that a single record's value changes for some unrelated field, the grouped-data is updated in place

This should also be true:
- if the edit is in the group-by field... the record should move to the new group with a full lengthy regroup. We misspoke earlier when we said that a complete regroup was required in this case, it should not be.
- if the edit is on the sort by field this should also be supported.

In the case where there is a full regroup, selection is being lost (as you observe). We're also looking at whether it is possible to perform a re-select in this case.

There were/are some subtle things to investigate in the code here and we still don't have these issue resolved for you, but we'll follow up when we do.

We'll also let you know if we make other changes in this area as part of this change.

Regards
Isomorphic Software

Great, thanks for the updates...

[Isomorphic]

We have now made a change in 9.1, 10.0 and 10.1 to address the issue where after a regroup selection is lost.

We've also made some changes to the 10.1 branch (the current active development branch) to avoid performing a time-consuming full regroup in the following cases:
- in response to an update on the sort-field of a record
- in response to an update which changes a record such that it is either added to or removed from the filtered-data set visible by the grid
- in response to an add or a remove operation effecting

Unfortunately we won't be able to port these enhancements back to 9.1 - they're a little too extensive and 10.1 has diverged significantly enough to make porting them back a little too involved given that these are performance enhancements rather than true bug fixes.

Just to keep you informed: These changes are also not in 10.0 - we may port back to that branch in the future, after some more extensive testing and analysis of the area.

Regards
Isomorphic Software

Thanks for the update. We can't roll to 10.x at this point in our schedule, but I'll try to roll soon as we start work on our next release. We will try to roll to the newer 9.1. Which nightly should I be looking for?

Also I noticed that when I have a standard grid layout (no grouping) and a record is filtered out because of an update and that record is selected, the grid record selection changes, but no event is fired to indicate this. Is that a defect or expected behavior?

Since we are displaying information based upon selection, right now every time we do an update we must capture the selection before and after the update and compare to figure out if the selection changed. This doesn't seem right.

[Isomorphic]

You can grab the latest nightly build from here to pick up the change which handles re-selecting on a full regroup.

You're right that we don't fire the selectionUpdated notification when the data changes such that the selected record disappears (due to change of filter, the record being deleted, or a complete 'setData' call from the code, etc).
This has long been how this has behaved, and is not something we'll be changing as a bug fix, as it would change behavior in a way which would potentially impact existing applications in unexpected ways.
(It's possible that in the future we will provide an option to turn such notifications on via an attribute on the grid, or similar. If this is of particular interest to you, you could always consider prioritizing this via feature sponsorship, but we wouldn't want to back port it to the 9.1 branch regardless)

Regards
Isomorphic Software

Great! Thank you for all of the help!

I tried pulling the 9/23 version or 4.1p down (which is the latest) and running my sample that I sent you again. With this version, the selection in the group is still lost when I group by the status field and update the status field. Also, I tried to get the exact version number I'm using. I use the following code in my app:

if (!GWT.isScript()) {
  // Add Ctrl-/ as launch mechanism for SmartGWT console.
  KeyIdentifier debugKey = new KeyIdentifier();
  debugKey.setCtrlKey(true);
  debugKey.setKeyName("/"); //$NON-NLS-1$
  Page.registerKey(debugKey, new PageKeyHandler() {
    @Override
    public void execute(String keyName) {
      SC.showConsole();
    }
  });
}

This was working until I rolled. Now that I've updated, this code sits in the SC.showConsole line for a really long time and eventually exceptions as follows:

11:09:00.643 [ERROR] [issues] 11:09:00.641:MOU7:WARN:Log:GWT uncaught exceptions have been encountered.  Check the Development Mode console for more details.

com.smartgwt.client.core.JsObject$SGWT_WARN: 11:09:00.641:MOU7:WARN:Log:GWT uncaught exceptions have been encountered.  Check the Development Mode console for more details.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:338)
    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:219)
    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:571)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeVoid(ModuleSpace.java:299)
    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeVoid(JavaScriptHost.java:107)
    at com.smartgwt.client.util.SC.logWarn(SC.java)
    at com.smartgwt.client.SmartGwtEntryPoint$1.onUncaughtException(SmartGwtEntryPoint.java:400)
    at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:244)
    at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:293)
    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
    at java.lang.Thread.run(Unknown Source)

So I am not able to verify for certain that my sample is running against the version I think I downloaded.

At least part of my issue seemed to be a cached issue. After clearing everything I can now get the console up and get the version number:

SmartClient Version: v9.1p_2014-09-23/LGPL Development Only (built 2014-09-23)

However, when I update the group by field I still lose selection.

[Isomorphic]

Looks like we missed a case - please try the next nightly build - September 26, and let us know if you continue to have problems with this.

Regards
Isomorphic Software

[Isomorphic]

Actually to follow up on this - you may want to hold off for the September 27th nightly - we've just added a few performance improvements for a full regroup which should have some impact on your particular usage of regrouping a very large set of data like this. This is in 9.1 and above.

Regards
Isomorphic Software

Just tried the one from 9/29. Looks good. Thanks!