|Re: Canceling a processing request (Busy handler custom implementation?) [message #1219818 is a reply to message #1212135]
||Thu, 05 December 2013 23:33
| Lukas Huser
Registered: March 2010
You probably won't need to implement your own busy handler for RAP. But you could try to honor the user's cancel request in a more timely fashion.
When a user cancels the current request, the following will happen:
a) the current client job (i.e. the current ClientSyncJob) is cancelled. Cancelling a job does not have any effect by itself, unless the job checks for the cancel flag and reacts in a reasonable way.
b) by default, Scout reacts as follows when the current client job is cancelled: if the client is waiting for the response of a remote service call from the server, it will send a cancel request to the server. The server will then cancel the current transaction (see ITransaction) which is associated with the current client request. The client immediately returns from the remote call (without returning any content/result).
From your description I guess that you are possibly performing some lenghty operation in the client model (i.e. any code in the different exec* methods in the client). In this case you could try to make your code more responsive to the cancel request by regularily checking whether the current job has been cancelled (through a call to the static method ClientJob.isCurrentJobCancelled()) and reacting accordingly.
Or you could try to do the computation asynchronously in the background and only report the result back to the UI (this could also be a reasonable approach if you are loading some large amount of data in a form or similar). You could adapt the code sample of the "polling" approach described by Beat in this post.
If your situation is totally different from what I assumed here, feel free to ask some more detailed questions.
Powered by FUDForum
. Page generated in 0.03125 seconds