[Isomorphic]

Thanks for the test case. This is under investigation and we'll get back to you as soon as we have anything to share.

Regards
Isomorphic Software

[bbaker]

We've implemented your first suggestion from post 29 (using updateCaches()). Delete performance has dramatically improved.
Yet add performance is degrading with the number of records in the grid.
We've attached our current sample code:

1. Launch Sample
2. Scroll to the last record
3. Select the last record
4. Click the 'Add 50 records (block)' button
5. Note the client locks up for around 8 to 10 seconds

Observations:

1. If you click the 'Add Record' button (which only adds a single record) it is much faster
2. If you change the sample to initialize with 10 records in the grid, you'll see that adding 50 records is a lot faster

We noticed some issues with Group By:

For this, change the sample code to initialize with 10 records and reduce the 'Add 50 records (block)' button handler to only add 5 records.

1. Launch sample
2. Group by Status column
3. Expand all the groups
4. Select a record from 1 of the groups
5. Click the 'Remove selected records (Block)' button
6. Note the record is removed
7. Select 2 records from a group with 2 or more items
8. Click the 'Remove selected records (Block)' button
9. Note the records do not disappear from the grid
10. Note the records have actually been removed but the display was not updated. If you ungroup you'll see the records are gone
11. Note same issue when adding more than 1 record using 'Add 50 records (Block)' button, again display does not update, but records have actually been added

Other notes:

We've considered the suggestion of filtering out deleted records, instead of removing them, which we believe is doable but does not address adds

Edit: formatting

[Isomorphic]

Removing Records from a ResultSet is prevented by design, since this doesn't make sense with pagination, although of course it's not intended to generate infinite warnings, we'll check on that aspect.

If you need to remove records from a ResultSet, you could either:

1. use updateCaches() just for the case of removal, while retaining your filterLocalData() approach for other updates

or

2. modify the data so that the Records no longer match criteria, so that filterLocalData() can be used to eliminate them

[bbaker]

We've integrated the Oct 30th build, updated our sample to call filterLocalData after the loop, and this has fixed the issues discussed above. Thanks! For consistency reasons, we'd like to add/remove records via the ResultSet, so we modified the sample to do so, but we get warnings that the ResultSet is 'read only' and the request is ignored. When removing records, the GWT log gets stuck in an infinite loop of these warnings, and locks up the browser. This may be a bug in the smartgwt framework, I've reattached the sample that produces the error.

Repro:
1. Launch sample
2. Select 1 or more grid items
3. Click 'Remove selected records'
4. Note the browser locks up, and warnings are infinitely output to the log

Is it possible to add/delete records via the result set? Or should we continue to do so directly on the grid?

[Isomorphic]

The big difference will be calling filterLocalData() outside the for loop, so you've updated all the cells you care about before refiltering.

Calling markForRedraw() should not actually be necessary for this particular usage, but it would not be expected to have any ill effect (filterLocalData() should already be handling marking the grid for redraw if the data has changed, and so an additional 'markForRedraw' call would see the grid was already dirty and just return).

Let us know if you aren't getting the desired behavior after this change.

[pgrever]

The reason we are doing both the call to fileterLocalData and markFor Redraw is your response from 17 Sep 14:22 where you stated: "So probably the best thing to do is directly update the Records in the ResultSet, then call ResultSet.filterLocalData() which specifically mentions this usage, then call listGrid.markForRedraw()." So, which is correct? Should we be calling markForRedraw or not?

[Isomorphic]

We have made a change to both the 5.0 and 5.1 branches which should address this issue.
Please try the next nightly build, dated Oct 30 or above.

As an aside - in your code you are calling filterLocalData after each change, and markForRedraw on the grid.
This should probably not be necessary - you can loop through making all the changes to the individual records and then perform a single 'filterLocalData' which will update the grid to properly display the modified records (including dropping records which no longer match search criteria, and shifting rows around so they sit correctly in their sorted position with their changed values). No need for multiple filterLocalDataCalls, and the markForRedraw should not be required as filterLocalData will notify the grid that its data has changed and cause it to refresh its rows

If any of the above problems continue to manifest with the new build, please let us know (and be sure to clearly indicate what the remaining problem is and how to repro)

Thanks
Isomorphic Software

[Isomorphic]

Yes - we have a possible framework fix for this - it looks like a bug in filterLocalData() which is putting the resultSet into a bad state with your particular usage. We're just doing some investigation to make sure the fix is safe to actually apply.
We'll keep you informed as soon as it goes in.

Regards
Isomorphic Software

[bbaker]

Hi, has there been any progress on this issue? Thanks

[Isomorphic]

OK, that's a good sanity check. Someone is assigned to dig into your test case soon, however as a quick guess: we think the ListGrid regards data as partially loaded due to an off-by-one in your ClientDataSource. This would explain both the "flash" and why filterLocalData() didn't work - it's only valid to call when all data is loaded (otherwise sorting cannot be done purely within the ResultSet). If this is the problem, you'll see a new request to your DataSource in the RPC tab of the Developer Console (and this is why there's a "flash" - the loading data message is briefly shown).

[bbaker]

I tried this, and I did not perceive a flash.

[Isomorphic]

Try this: go here (and reload the page if you already had the showcase open):

http://www.smartclient.com/smartgwt/...ured_grid_live

Open the Developer Console and execute "isc_ListGrid_0.redraw()" using the "Evaluate JS Expression" area of the Results tab in the Developer Console.

If you are able to perceive a "flash" something basic is wrong with your machine - at the video driver / display settings level.

[bbaker]

To be more specific, the grid text content visibly disappears, then reappears. The buttons outside of the grid remain static. I'm running the samples out of eclipse.
I've seen the 'flash' occur in Super and Classic Development mode in IE11 and Chrome. I've attached the missing source file. I can' think of any special settings that may be configured to cause this behavior. Do you know what settings these are specifically? Thanks

[Isomorphic]

Also - we're missing a Class here - the "ClientDataSource" - could you upload the source for that (or show us the code inline) please?

Thanks

[Isomorphic]

Hi bbaker, can you clarify: you say the "browser content flashes for a redraw". A redraw is both necessary in this case, and explicitly asked for by your code (grid.markForRedraw()). However, a redraw does not normally cause any kind of "flash". If you perceive a "flash" during redraws *in general*, you may have special browser settings active that create that flash, whereas a system with normal settings would not have a flash.

So, can you clarify what you mean by "flash", and whether you see it on a normal system?