Closed vpenades closed 3 years ago
Interesting idea. I think your first suggestion would be a good fit.
Having a private CancellationTokenSource
that can be used to expose the CancellationToken
to DoWork
, and that can also be used to trigger the cancellation as a response to the user cancelling the dialog make sense to me.
The only thing I'm pondering is that it might be better (in terms of API) to allow users to provide a CancellationToken
instead of a custom CancellationTokenSource
.
What do you think about the following:
Show
and ShowDialog
that can receive a CancellationToken
CancellationTokenSource
, owned by the dialog, that is directly linked to the CancellationToken
provided i.e. CancellationTokenSource.CreateLinkedTokenSource
CancellationToken
via DoWorkEventArgs
var dlg = new Ookii.Dialogs.Wpf.ProgressDialog();
dlg.DoWork += (s, e) =>
{
MyJob(dlg, e.CancellationToken);
};
dlg.ShowDialog(cancellationToken);
Eventually (in a future PR) we could also consider listening to the CancellationToken
cancellation and close the dialog automatically if the job is cancelled by some event in the code and not by the user (i.e. cancellationToken.Register(...)
).
:tada: This issue has been resolved in Ookii.Dialogs.Wpf v4.0.0
The release is available on:
I have a job action that is declared like this:
And I want to use it along with ProgressDialog.
ProgressDialog already supports IProgress , but I haven't seen a way to connect the CancellationToken with the ProgressDialog, so right now I'm doing something like this:
Solutions:
ProgressDialog
be configured with aSystem.Threading.CancellationTokenSource
, so when the user clicks Cancel, it will propagate the cancellation to the tokens. Also add a CancellationToken to DoWorkEventArgs, so it can be used by the job.dlg.CancelJob += (s,e) => tokenSource.Cancel();
Given that DotNet is moving towards Task and async/await, so more and more system methods are using CancellationToken, I would suggest to adopt the first solution.
PR?