A Cancel button should request cancellation and then report what actually happened. Hiding a progress bar is not enough. Some work may already be complete, an external operation may still be finishing, or the task may fail independently before it observes the request.
Microsoft's C# cancellation example shows a cancellation source signaling a token and the application awaiting the resulting task outcome. That separation helps define an honest interface contract.
Decide what the user is canceling
Name the operation: copying one file, transferring several files or preparing an export are different scopes. A single button should not ambiguously mean all current work and only the selected item at the same time.
InTray describes desktop file handling and appears in the C# catalogue. Its listing provides a relevant workflow category, not evidence about its cancellation code. The review below applies to an application you control.
For a batch operation, decide whether already completed items remain available. Show that decision before a user must discover it through trial and error.
Model the transition explicitly
Represent “cancellation requested” separately from “canceled.” While the task is still resolving, prevent conflicting actions that would make its outcome unclear.
If the task completes before cancellation takes effect, show completion. If it observes cancellation after processing some items, show the partial result and the remaining work. If it fails for another reason, preserve that error rather than relabeling every concurrent failure as cancellation.
This distinction is useful for support as well as users. A single canceled label can otherwise hide whether data was written.
Pass the request through the work
In code you own, trace whether the cancellation token reaches the operations that support it. A top-level token cannot influence a lower-level call that never observes it.
For work that cannot be interrupted safely, define a boundary at which cancellation will take effect. The interface can explain that the current step will finish while later steps will not start.
Avoid promising immediate reversal. Stopping future work and undoing completed side effects are separate product capabilities.
Protect the next operation from the previous one
After requesting cancellation, a user may start another task quickly. Ensure that late progress or completion from the earlier task cannot replace the new task's status.
Use operation identity in the state model, and release resources according to the task's actual lifecycle. Reusing a screen is not evidence that the previous operation has ended.
Test this with distinguishable synthetic files so a delayed callback is easy to recognize.
Rehearse the timing cases
Exercise cancellation before work starts, during a long step and immediately before completion. Include an unavailable destination and a batch containing one successful item followed by a failure.
Record both the final interface and the resulting files or records. The visible state should explain the durable outcome.
The companion C# file-import boundary guide covers another side of the same desktop workflow: treating incoming file references carefully. Clear input ownership and clear cancellation semantics make asynchronous work easier to trust and maintain.
Stardew Valley Tracker
IcyZip
Xeramail Temp Mail