SortEvent and onSortChanged

[stonebranch2]

1. SmartClient Version: v9.1p_2014-04-29/Pro Deployment (built 2014-04-29)

2. FF ESR 24.5.0

3. N/A

4. N/A

5. N/A

6.

It would appear that every time listGrid.setData (see code snippet below) is called, a SortEvent fires and onSortChanged(SortEvent) is called on my SortChangedHandler. Any suggestion for how I can react only to Sort Changed events driven manually by the user (i.e. context-menu Sort Ascending, Sort Descending, Configure Sort, Clear Sort, etc.). I found the SorterClickHandler, but that only captures clicks on the corner sorter. Or is there something I can do to prevent a SortEvent from firing when calling listGrid.setData in this case?

listGrid.getDataSource().fetchData(criteria, new DSCallback() {
@Override
public void execute(DSResponse response, Object rawData, DSRequest request) {
DataSource dataSource = listGrid.getDataSource();

ResultSet resultSet = new ResultSet(dataSource);
resultSet.setInitialLength(response.getTotalRows());
resultSet.setInitialData(response.getData());
resultSet.setInitialSort(listGrid.getSort());
resultSet.setCriteria(listGrid.getCriteria());

listGrid.setData(resultSet);
}

}, request);


Thanks

[Isomorphic]

Sort does indeed change in this circumstance because the current sort is discarded.

We're not sure what your handler code does in this case that's undesirable, but if you have no other condition that you can check to avoid taking the wrong action, you can always simply set a one-time flag before you call setData() and have your handler about if it sees that flag.

[stonebranch2]

OK, thanks. I thought about that option, but was hoping there was an alternative. I will try to work with this option.

This grid will update very frequently on a timer (without user intervention), and each time the grid updates, it could be potentially replaced with a entirely new set of data, or potentially the data could remain unchanged. In the case where some or all of the data remains unchanged (i.e the new ResultSet has the same record in the same row) and that particular row was selected prior to the refresh (i.e via right-click context menu), I would like to preserve the selection during the grid refresh so that the user can continue to proceed with the operation on that record. With the current approach, the selection is always cleared and when the user proceeds with the operation, it fails with no record selected. In other words, if the selected record does not change due to the grid refresh, I want it to be completely undetectable by the user. I also need to perform the grid update in the most efficient way. There will be a fixed maximum number of records in the grid at any time, so I considered comparing the incoming result set with the current grid result set and update each record in the grid accordingly rather than calling setData. Any recommendations here would be appreciated.

Thanks

[Isomorphic]

Sounds like a straightforward use of get/setSelectedState(), but also take a look at get/setViewState in case you want to preserve more than just the selection (such as the current sort).

[stonebranch2]

OK, thank you, I was able to preserve the current selection using your suggestion as follows.

String selectionState = listGrid.getSelectedState();
listGrid.setData(resultSet);
listGrid.setSelectedState(selectionState);

I assume that is what you intended.

However, I do see something that is problematic. If I happen to have the context-menu open at the time of the automatic grid refresh, the currently highlighted (blue) context-menu item is temporarily unhighlighted, there is a slight hang, and then the menu item becomes highlighted (blue) again.

Is there a way I can make the grid refresh undetectable?

Thanks

[Isomorphic]

See rpcRequest.showPrompt. Assuming you are using fetchData() to retrieve the new data, you'll want to set showPrompt:false on via the dsRequest Properties argument.

[stonebranch2]

Thanks,

Yes, using fetchData(). I was experimenting with that (noticed it mentioned in thread http://forums.smartclient.com/showthread.php?t=28360), but it was hard to tell if there was an improvement running in development mode, however, definitely seeing improvement verifying that change in compiled mode.

There is still a slight hiccup during the refresh, for example, if I have a window open above the grid with a form that I am in the process of typing text into, when the refresh occurs, there will be a slight lag in my typing. The ResultSet size I am currently working with is approximately 25 records or less.

Here is a snippet of the refresh request.

DSRequest request = new DSRequest();
request.setStartRow(startRow);
request.setEndRow(endRow);
request.setSortBy(listGrid.getSort());
request.setShowPrompt(Boolean.FALSE);

dataSource.fetchData(criteria, new DSCallback() {
@Override
public void execute(DSResponse response, Object rawData, DSRequest request) {
DataSource dataSource = listGrid.getDataSource();

Record[] recordList = response.getData();
int length = (recordList == null) ? 0 : recordList.length;
ResultSet resultSet = new ResultSet(dataSource);
resultSet.setInitialLength(length);
resultSet.setInitialData(recordList);
resultSet.setInitialSort(listGrid.getSort());
resultSet.setCriteria(criteria);
resultSet.setAllRows(recordList);

String selectionState = listGrid.getSelectedState();
listGrid.setData(resultSet);
listGrid.setSelectedState(selectionState);

scheduleTimer(timerDelay);
}
}, request);

Do you have any other suggestions that I can take advantage of to further optimize what I am doing here to minimize UI interruptions during the redraw?

In addition to the above, I'd like to schedule the next refresh only after the list grid redraw has completed. I can force a redraw immediately after setting the data, but the documentation discourages this unless it is a necessity. I'd prefer not to force an immediate redraw if this will impact performance or responsiveness in the UI (will it?), however, I didn't have much luck experimenting with the DrawHandler. It appears that handler only fires when the initial grid is drawn, not when the new data is finished being rendered.

Thanks

[Isomorphic]

We use this approach routinely and in fact it's covered on the public wiki, and, in our testing, it takes negligible time and has no perceptible lag.

Take a look at the FAQ for some reasons why it could have lag in your testing, for example, testing with various development tools active.

If you need more help with this, we'd suggest using our Consulting services, because at this point, given that you are using an approach that we know works, you would need hands-on, "looking over your shoulder" type of help to see exactly what you're seeing and figure out what's different about your environment.

[stonebranch2]

I am aware that the pattern is covered on the public wiki, because that is the example I built from.

As I noted, in compiled/deployed mode, the impact is minimal now that I have incorporated the showPrompt:false, and I can see, if I were not in the middle of typing text into an input field, the refresh would not be perceptible. But if you pop up a window above the grid and continue to type throughout the refresh, you can notice a subtle and very quick pause in typing right as it redraws and perhaps that fits within your definition of "it takes negligible time and has no perceptible lag".

I was only trying to be sure that if there are additional best practices to keep performance optimal under this scenario that I am incorporating them, as there could be multiple instances of these grids open at a time. Furthermore, additional concern came from the other post I referenced where there was a comment about update performance right before thread ended, and there was no follow up.

From what I can gather, I am following the best practices here.

Thanks for your help.

Regards

[Isomorphic]

Your code is a near-copy of the wiki article. In that sense, you're following best practices.

You should still revisit the FAQ for all the ways in which you might be interfering with performance and/or your measurement of performance.