I know we cannot cancel an asynchronous call to the DataPortal, but we need the ability to at a minimum ignore it. We are in the process of converting to CSLA 4 and we used to have this ability in our asynchronous logic and we need it still (otherwise we will have to change a lot of our UI code).
Here is our scenario:
We have forms and controls (search forms, loaded on demand controls, etc.) that get loaded asynchronously. While they are being loaded the User may close the forms/controls and since we cannot tell the asynchronous call logic to ignore the results, we get exceptions that objects are null. Furthermore, when it comes to searches, the user have the ability to stop the call (ignore results if the asynchronous call already started) and search again with different criteria. This means that they could have canceled 3 calls and be waiting for the 4th to come back. I’m mentioning this to show that just putting code in the callback/event to ignore without know which call is being returned would not help.
I could probably come up with a solution, but I do not want to reinvent the wheel if someone has already done something to make this feasible, since I would think it is not that uncommon for user to want to cancel asynchronous calls (or have the appearance of canceling-ignoring) without having to kill the entire application.
The answer to the last question in this post (http://forums.lhotka.net/forums/t/3570.aspx) may be what we are looking for.
The async dataportal calls uses a BackgroundWorker but the internal BackgroundWorker is not exposed to you.
I would suggest that you use the Csla.Threading.BackgroundWorker to do the async call.
Create new instance of Backgroundworker for each async call and keep the latest in a variable (CurrentBW).
Set CurrentBW.WorkerSupportsCancellation to true and a syncronous DataPortal call in the DoWork method (already on a background thread).
When user wants to cancel the running request your code should call the CanceAsync() method on the BackgroundWorker.
In the RunWorkerCompleted (when async call returns to the UI thread) you should test for e.Cancelled before updating the UI.
Your DoWork and RunWorkerCompleted methods would be defined in your form and can be reused.
Please be aware that
BackgroundWorker will throw an Exception if you try to read e.Result when e.Error is NOT NULL.
Copyright (c) Marimer LLC