ResultSet.getRange showPrompt=true

[jpappalardo]

Is it possible to cause ResultSet.getRange from to create a request with showPrompt = true?

We have been confused for quite some time why our UI seems to block on asynchronous requests to the server. It appears that ListGrids, TreeGrids, and our self created ResultSets send requests with showPrompt=true. We have been experiencing this issue since SmartGWT 2.5 and continue to see the problem in SmartGWT 6.0. Setting RPCManager.setShowPrompt(false) appears to have no effect on this behavior, and am unable to find documentation elsewhere on how this behavior can be changed. I presume that the Grids are only blocking the rendered grid and not the entire UI with showPrompt=true. Is there a way we can disable this on our ResultSets, or provide a hidden container for it to block on that does not effect the entire UI? I am guessing that the reality is we need to move away from using ResultSets ourselves in our code.

[Isomorphic]

This is expected - DataSource.showPrompt is a more specific property and defaults to true.

These requests block the entire UI to avoid you having to write a lot of code like "if (data is not yet loaded)" throughout your UI. We would recommend leaving the default setting alone, as you probably have a lot of code that would just crash if the end user was allowed to access the UI in the middle of data loading.

However for atypical cases such as a background data refresh, you can pass showPrompt:false anywhere you see DSRequest Properties as an argument.

For a hand-created ResultSet, there's not currently a documented way to set request properties, but you could use a specific operationId via resultSet.fetchOperation, then use DataSource.transformRequest to flip showPrompt to false when you see that operationId.

[jpappalardo]

I can see where blocking widgets while a request is happening on a DS can be useful, but I am not clear why this should block the entire UI, and now allow for setting a target canvas to block so that users could continue using other parts of the UI while another component handles its server interaction. That is just my two cents though.

[Isomorphic]

What usually breaks is, for example, code in a Button that is next to a grid and acts on the data within that grid. Blocking just the grid doesn't solve that case or indeed any of the most common cases. But there is nothing preventing you from using finer-grained blocking in cases where it makes sense.

[jpappalardo]

Agreed, but if a developer desired to say place the grid and the buttons into a container, and then have that container block, but not the rest of the UI, that would seem a reasonable solution?

[Isomorphic]

Yes, for that scenario, use canvas.showComponentMask() and set showPrompt:false to avoid whole-screen masking.

Again it's a relatively rare app where there is a request that takes a long time and there are UI elements where a user could be getting meaningful work done while only part of the UI is blocked. We wouldn't recommend getting into the complexity of partially blocking the UI if your concern is that technically a user should be able to access a particular menu during the 0.25 seconds the grid is fetching (for example).

But if you really do have a scenario where partial blocking makes sense, showComponentMask is designed for this situation.