{"id":1519,"date":"2024-12-10T18:32:43","date_gmt":"2024-12-10T18:32:43","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/12\/10\/invoking-async-power-what-awaits-winforms-in-net-9\/"},"modified":"2024-12-10T18:32:43","modified_gmt":"2024-12-10T18:32:43","slug":"invoking-async-power-what-awaits-winforms-in-net-9","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/12\/10\/invoking-async-power-what-awaits-winforms-in-net-9\/","title":{"rendered":"Invoking Async Power: What Awaits WinForms in .NET 9"},"content":{"rendered":"

As .NET continues to evolve, so do the tools available to WinForms developers,
\nenabling more efficient and responsive applications. With .NET 9, we\u2019re excited
\nto introduce a collection of new asynchronous APIs that significantly streamline
\nUI management tasks. From updating controls to showing forms and dialogs, these
\nadditions bring the power of async programming to WinForms in new ways. In this
\npost, we\u2019ll dive into four key APIs, explaining how they work, where they shine,
\nand how to start using them.<\/p>\n

Meet the New Async APIs<\/h2>\n

.NET 9 introduces several async APIs designed specifically for WinForms, making
\nUI operations more intuitive and performant in asynchronous scenarios. The new
\nadditions include:<\/p>\n

Control.InvokeAsync<\/strong> \u2013 Fully released in .NET 9, this API helps marshal
\ncalls to the UI thread asynchronously.
\nForm.ShowAsync<\/strong> and Form.ShowDialogAsync<\/strong> (Experimental) \u2013 These APIs
\nlet developers show forms asynchronously, making life easier in complex UI
\nscenarios.
\nTaskDialog.ShowDialogAsync<\/strong> (Experimental) \u2013 This API provides a way to
\nshow Task-Dialog-based message box dialogs asynchronously, which is especially
\nhelpful for long-running, UI-bound operations.<\/p>\n

Let\u2019s break down each set of APIs, starting with InvokeAsync.<\/p>\n

Control.InvokeAsync: Seamless Asynchronous UI Thread Invocation<\/h3>\n

InvokeAsync offers a powerful way to marshal calls to the UI thread without
\nblocking the calling thread. The method lets you execute both synchronous and
\nasynchronous callbacks on the UI thread, offering flexibility while preventing
\naccidental \u201cfire-and-forget\u201d behavior. It does that by queueing operations in
\nthe WinForms main message queue, ensuring they\u2019re executed on the UI thread.
\nThis behavior is similar to Control.Invoke, which also marshals calls to
\nthe UI thread, but there\u2019s an important difference: InvokeAsync doesn\u2019t block
\nthe calling thread because it posts<\/em> the delegate to the message queue, rather
\nthan sending<\/em> it.<\/p>\n

Wait \u2013 Sending vs. Posting? Message Queue?<\/h3>\n

Let\u2019s break down these concepts to clarify what they mean and why
\nInvokeAsync\u2018s approach can help improve app responsiveness.<\/p>\n

In WinForms, all UI operations happen on the main UI thread. To manage these
\noperations, the UI thread runs a loop, known as the message loop, which
\ncontinually processes messages\u2014like button clicks, screen repaints, and other
\nactions. This loop is the heart of how WinForms stays responsive to user actions
\nwhile processing instructions. When you are working with modern APIs, the
\nmajority of your App\u2019s code does not run on this UI thread. Ideally, the UI
\nthread should only be used to do those things which are necessary to update
\nyour UI. There are situations when your code doesn\u2019t end up on
\nthe UI Thread automatically. One example is when you
\nspin-up a dedicated task to perform a
\ncompute-intense operation in parallel.
\nIn these cases, you need to \u201cmarshal\u201d the code execution to the UI thread, so that
\nthe UI thread then can update the UI. Because otherwise it\u2019s this:<\/p>\n\n

Let\u2019s say I am not allowed to go into a certain room to get a glass of
\nmilk, but you are. In that case, there is only one option: Since I cannot become
\nyou, I can only ask you to get me that glass of milk. And that\u2019s the same with
\nthread marshalling. A worker thread cannot become the UI thread. But the
\nexecution of code (the getting of the glass of milk) can be marshalled. In other
\nwords: the worker thread can ask the UI Thread to execute some code on its
\nbehalf. And, simply put, that works by queuing the delegate of a method into the message
\nqueue.<\/p>\n

And with that, lets address this Sending<\/em> and Posting<\/em> confusion: You have two
\nmain ways to queue up actions in this loop:<\/p>\n

Sending a Message (Blocking):<\/strong> Control.Invoke uses this approach. When you
\ncall Control.Invoke, it synchronously sends the specified delegate to the UI
\nthread\u2019s message queue. This action is blocking, meaning the calling thread
\nwaits until the UI thread processes the delegate before continuing. This is
\nuseful when the calling code depends on an immediate result from the UI thread
\nbut can lead to UI freezes if overused, especially during long-running
\noperations.<\/p>\n

Posting a Message (Non-Blocking):<\/strong> InvokeAsync posts the delegate to the
\nmessage queue, which is a non-blocking operation. This approach tells the UI
\nthread to queue up the action and handle it as soon as it can, but the calling
\nthread doesn\u2019t wait around for it to finish. The method returns immediately,
\nallowing the calling thread to continue its work. This distinction is
\nparticularly valuable in async scenarios, as it allows the app to handle other
\ntasks without delay, minimizing UI thread bottlenecks.<\/p>\n

Here\u2019s a quick comparison:<\/p>\n

Operation
\nMethod
\nBlocking
\nDescription<\/p>\n

Send<\/strong>
\nControl.Invoke
\nYes
\nCalls the delegate on the UI thread and waits for it to complete.<\/p>\n

Post<\/strong>
\nControl.InvokeAsync
\nNo
\nQueues the delegate on the UI thread and returns immediately.<\/p>\n

Why This Matters<\/h3>\n

By posting delegates with InvokeAsync, your code can now queue multiple
\nupdates to controls, perform background operations, or await other async tasks
\nwithout halting the main UI thread. This approach not only helps prevent the
\ndreaded \u201cfrozen UI\u201d experience but also keeps the app responsive even when
\nhandling numerous UI-bound tasks.<\/p>\n

In summary: while Control.Invoke waits for the UI thread to complete the
\ndelegate (blocking), InvokeAsync hands off the task to the UI thread and
\nreturns instantly (non-blocking). This difference makes InvokeAsync ideal for
\nasync scenarios, allowing developers to build smoother, more responsive WinForms
\napplications.<\/p>\n

Here\u2019s how each InvokeAsync overload works:<\/p>\n

public async Task InvokeAsync(Action callback, CancellationToken cancellationToken = default)
\npublic async Task<T> InvokeAsync<T>(Func<T> callback, CancellationToken cancellationToken = default)
\npublic async Task InvokeAsync(Func<CancellationToken, ValueTask> callback, CancellationToken cancellationToken = default)
\npublic async Task<T> InvokeAsync<T>(Func<CancellationToken, ValueTask<T>> callback, CancellationToken cancellationToken = default)<\/p>\n

Each overload allows for different combinations of synchronous and asynchronous
\nmethods with or without return values:<\/p>\n

InvokeAsync(Action callback, CancellationToken cancellationToken = default) is
\nfor synchronous operations with no<\/em> return value. If you want to update a
\ncontrol\u2019s property on the UI thread\u2014such as setting the Text property on a
\nLabel\u2014this overload allows you to do so without waiting for a return value. The
\ncallback will be posted to the message queue and executed asynchronously,
\nreturning a Task that you can await if needed.<\/p>\n

await control.InvokeAsync(() => control.Text = “Updated Text”);<\/p>\n

InvokeAsync<T>(Func<T> callback, CancellationToken cancellationToken = default) is for synchronous operations that do<\/em> return a result of type T.
\nUse it when you want to retrieve a value computed on the UI thread, like getting
\nthe SelectedItem from a ComboBox. InvokeAsync posts the callback to the UI
\nthread and returns a Task<T>, allowing you to await the result.<\/p>\n

int itemCount = await control.InvokeAsync(() => comboBox.Items.Count);<\/p>\n

InvokeAsync(Func<CancellationToken, ValueTask> callback, CancellationToken cancellationToken = default): This overload is for asynchronous<\/em> operations
\nthat don\u2019t<\/em> return a result. It\u2019s ideal for a longer-running async operation
\nthat updates the UI, such as waiting for data to load before updating a control.
\nThe callback receives a CancellationToken<\/em> to support cancellation and need to
\nreturn a ValueTask<\/em>, which InvokeAsync will await (internally) for
\ncompletion, keeping the UI responsive while the operation runs asynchronously.
\nSo, there are two \u201cawaits happening\u201d: InvokeAsync is awaited (or rather can be
\nawaited), and internally the ValueTask that you passed is also awaited.<\/p>\n

await control.InvokeAsync(async (ct) =>
\n{
\n await Task.Delay(1000, ct); \/\/ Simulating a delay
\n control.Text = “Data Loaded”;
\n});<\/p>\n

InvokeAsync<T>(Func<CancellationToken, ValueTask<T>> callback, CancellationToken cancellationToken = default) is then finally the overload
\nversion for asynchronous<\/em> operations that do<\/em> return a result of type T. Use
\nit when an async operation must complete on the UI thread and return a value,
\nsuch as querying a control\u2019s state after a delay or fetching data to update the
\nUI. The callback receives a CancellationToken and returns a ValueTask<T>,
\nwhich InvokeAsync will await to provide the result.<\/p>\n

var itemCount = await control.InvokeAsync(async (ct) =>
\n{
\n await Task.Delay(500, ct); \/\/ Simulating data fetching delay
\n return comboBox.Items.Count;
\n});<\/p>\n

Quick decision lookup: Choosing the Right Overload<\/h3>\n

For no return value with synchronous operations, use Action.
\nFor return values with synchronous operations, use Func<T>.
\nFor async operations without a result, use Func<CancellationToken, ValueTask>.
\nFor async operations with a result, use Func<CancellationToken, ValueTask<T>>.<\/p>\n

Using the correct overload helps you handle UI tasks smoothly in async WinForms applications, avoiding main-thread bottlenecks and enhancing app responsiveness.<\/p>\n

Here\u2019s a quick example:<\/p>\n

var control = new Control();<\/p>\n

\/\/ Sync action
\nawait control.InvokeAsync(() => control.Text = “Hello, async world!”);<\/p>\n

\/\/ Async function with return value
\nvar result = await control.InvokeAsync(async (ct) =>
\n{
\n control.Text = “Loading…”;
\n await Task.Delay(1000, ct);
\n control.Text = “Done!”;
\n return 42;
\n});<\/p>\n

Mixing-up asynchronous and synchronous overloads happen \u2013 or do they?<\/h3>\n

With so many overload options, it\u2019s possible to mistakenly pass an async method
\nto a synchronous overload, which can lead to unintended \u201cfire-and-forget\u201d
\nbehavior. To prevent this, WinForms introduces for .NET 9 a WinForms-specific
\nanalyzer that detects when an asynchronous method (e.g., one returning Task) is
\npassed to a synchronous overload of InvokeAsync without a CancellationToken.
\nThe analyzer will trigger a warning, helping you identify and correct potential
\nissues before they cause runtime problems.<\/p>\n

For example, passing an async method without CancellationToken support might
\ngenerate a warning like:<\/p>\n

warning WFO2001: Task is being passed to InvokeAsync without a cancellation token.<\/p>\n

This Analyzer ensures that async operations are handled correctly, maintaining
\nreliable, responsive behavior across your WinForms applications.<\/p>\n

Experimental APIs<\/h2>\n

In addition to InvokeAsync, WinForms introduces experimental async options for
\n.NET 9 for showing forms and dialogs. While still in experimental stages, these
\nAPIs provide developers with greater flexibility for asynchronous UI
\ninteractions, such as document management and form lifecycle control.<\/p>\n

Form.ShowAsync and Form.ShowDialogAsync are new methods that allow forms to
\nbe shown asynchronously. They simplify the handling of multiple form instances
\nand are especially useful in cases where you might need several instances of the
\nsame form type, such as when displaying different documents in separate windows.<\/p>\n

Here\u2019s a basic example of how to use ShowAsync:<\/p>\n

var myForm = new MyForm();
\nawait myForm.ShowAsync();<\/p>\n

And for modal dialogs, you can use ShowDialogAsync:<\/p>\n

var result = await myForm.ShowDialogAsync();
\nif (result == DialogResult.OK)
\n{
\n \/\/ Perform actions based on dialog result
\n}<\/p>\n

These methods streamline the management of asynchronous form displays and help
\nyou avoid blocking the UI thread while waiting for user interactions.<\/p>\n

TaskDialog.ShowDialogAsync<\/h3>\n

TaskDialog.ShowDialogAsync is another experimental API in .NET 9, aimed at
\nimproving the flexibility of dialog interactions. It provides a way to show task
\ndialogs asynchronously, perfect for use cases where lengthy operations or
\nmultiple steps are involved.<\/p>\n

Here\u2019s how to display a TaskDialog asynchronously:<\/p>\n

var taskDialogPage = new TaskDialogPage
\n{
\n Heading = “Processing…”,
\n Text = “Please wait while we complete the task.”
\n};<\/p>\n

var buttonClicked = await TaskDialog.ShowDialogAsync(taskDialogPage);<\/p>\n

This API allows developers to asynchronously display dialogs, freeing the UI
\nthread and providing a smoother user experience.<\/p>\n

Practical Applications of Async APIs<\/h2>\n

These async APIs unlock new capabilities for WinForms, particularly in
\nmulti-form applications, MVVM design patterns, and dependency injection
\nscenarios. By leveraging async operations for forms and dialogs, you can:<\/p>\n

Simplify form lifecycle management<\/strong> in async scenarios, especially when
\nhandling multiple instances of the same form.
\nSupport MVVM and DI workflows<\/strong>, where async form handling is beneficial in
\nViewModel-driven architectures.
\nAvoid UI-thread blocking<\/strong>, enabling a more responsive interface even during
\nintensive operations.<\/p>\n

If you curious about how Invoke.Async can revolutionize AI-driven
\nmodernization of WinForms apps then check out this .NET Conf 2024
\ntalk<\/a> to see these features
\ncome alive in real-world scenarios!<\/p>\n

\u00a0<\/p>\n\n

And that\u2019s not all\u2014don\u2019t miss our deep dive into everything new in .NET 9 for
\nWinForms in another exciting
\ntalk<\/a>. Dive in and get
\ninspired!<\/p>\n

How to Kick Off Something Async from Something Sync<\/h3>\n

In UI scenarios, it\u2019s common to trigger async operations from synchronous
\ncontexts. Of course, we all know it\u2019s best practice to avoid async void
\nmethods.<\/p>\n

Why is this the case? When you use async void, the caller has no way to await
\nor observe the completion of the method. This can lead to unhandled exceptions
\nor unexpected behavior. async void methods are essentially fire-and-forget,
\nand they operate outside the standard error-handling mechanisms provided by
\nTask. This makes debugging and maintenance more challenging in most scenarios.<\/p>\n

But! There is an exception, and that is event handlers or methods with \u201cevent
\nhandler characteristics.\u201d Event handlers cannot return Task or Task<T>, so
\nasync void allows them to trigger async actions without blocking the UI
\nthread. However, because async void methods aren\u2019t awaitable, exceptions are
\ndifficult to catch. To address this, you can use error-handling constructs like
\ntry-catch around the awaited operations inside the event handler. This ensures
\nthat exceptions are properly handled even in these unique cases.<\/p>\n

For example:<\/p>\n

private async void Button_Click(object sender, EventArgs e)
\n{
\n try
\n {
\n await PerformLongRunningOperationAsync();
\n }
\n catch (Exception ex)
\n {
\n MessageBox.Show($”An error occurred: {ex.Message}”, “Error”, MessageBoxButtons.OK, MessageBoxIcon.Error);
\n }
\n}<\/p>\n

Here, the async void is unavoidable due to the event handler signature, but by
\nwrapping the awaited code in a try-catch, we can safely handle any exceptions
\nthat might occur during the async operation.<\/p>\n

The following example uses a 7-Segment control named SevenSegmentTimer to
\ndisplay a timer in the typical 7-segment-style with the resolution of a 10th of
\na second. It has a few methods for updating and animating the content:<\/p>\n

public partial class TimerForm : Form
\n{
\n private SevenSegmentTimer _sevenSegmentTimer;
\n private readonly CancellationTokenSource _formCloseCancellation = new();<\/p>\n

public FrmMain()
\n {
\n InitializeComponent();
\n SetupTimerDisplay();
\n }<\/p>\n

[MemberNotNull(nameof(_sevenSegmentTimer))]
\n private void SetupTimerDisplay()
\n {
\n _sevenSegmentTimer = new SevenSegmentTimer
\n {
\n Dock = DockStyle.Fill
\n };<\/p>\n

Controls.Add(_sevenSegmentTimer);
\n }<\/p>\n

override async protected void OnLoad(EventArgs e)
\n {
\n base.OnLoad(e);
\n await RunDisplayLoopAsyncV1();
\n }<\/p>\n

private async Task RunDisplayLoopAsyncV1()
\n {
\n \/\/ When we update the time, the method will also wait 75 ms asynchronously.
\n _sevenSegmentTimer.UpdateDelay = 75;<\/p>\n

while (true)
\n {
\n \/\/ We update and then wait for the delay.
\n \/\/ In the meantime, the Windows message loop can process other messages,
\n \/\/ so the app remains responsive.
\n await _sevenSegmentTimer.UpdateTimeAndDelayAsync(
\n time: TimeOnly.FromDateTime(DateTime.Now));
\n }
\n }
\n}<\/p>\n

When we run this, we see this timer in the Form on the screen:<\/p>\n\n

The async method UpdateTimeAndDelayAsync does exactly what it says: It updates
\nthe time displayed in the control, and then waits the amount of time, which
\nwe\u2019ve set with the UpdateDelay property the line before.<\/p>\n

As you can see, this async method RunDisplayLoopAsyncV1 is kicked-off in the
\nForm\u2019s OnLoad. And that\u2019s the typical approach, how we initiate something
\nasync from a synchronous void method.<\/p>\n

For the typical WinForms dev this may look a bit weird on first glance. After
\nall, we\u2019re calling another method from OnLoad, and that method never returns
\nbecause it\u2019s ending up in an endless loop. So, does OnLoad in this case ever
\nfinish? Aren\u2019t we blocking the app here?<\/p>\n

This is where async programming shines. Even though RunDisplayLoopAsyncV1
\ncontains an infinite loop, it\u2019s structured asynchronously. When the await
\nkeyword is encountered inside the loop (e.g., await _sevenSegmentTimer.UpdateTimeAndDelayAsync()), the method yields control back
\nto the caller until the awaited task completes.<\/p>\n

In the context of a WinForms app, this means the Windows message loop remains
\nfree to process events like repainting the UI, handling button clicks, or
\nresponding to keyboard input. The app stays responsive because await pauses
\nthe execution of RunDisplayLoopAsyncV1 without blocking the UI thread.<\/p>\n

When OnLoad is marked async, it completes as soon as it encounters its first
\nawait within RunDisplayLoopAsyncV1. After the awaited task completes, the
\nruntime resumes execution of RunDisplayLoopAsyncV1 from where it left off.
\nThis happens without blocking the UI thread, effectively allowing OnLoad to
\nreturn immediately, even though the asynchronous operation continues in the
\nbackground.<\/p>\n

In the background? You can think of this as splitting the method into parts,
\nlike an imaginary WaitAsync-Initiator, which gets called after the first
\nawait is resolved. Which then kicks-off the WaitAsync-Waiter which runs in
\nthe background, until the wait period is over. Which then again triggers the
\nWaitAsync-Callback which effectively asks the message loop to reentry the call
\nand then complete everything which follows that async call.<\/p>\n

So, the actual code path looks then something like this:<\/p>\n\n

And the best way to internalize this is to compare it to 2 mouse-click events,
\nwhich have been processed in succession, where the first mouse-click kicks off
\nRunDisplayLoopAsyncV1, and the second mouse-click corresponds to the
\nWaitAsync call-back into \u201cPart 3\u201d of that method, when the delay is just ready
\nwaiting.<\/p>\n

This process then repeats for each subsequent await in an async method. And
\nthis is why the app doesn\u2019t freeze despite the infinite loop. In fact,
\ntechnically, OnLoad actually finishes normally, but the part(s) after each await
\nare called back by the message loop later in time.<\/p>\n

Now, we\u2019re still pretty much using the UI Thread exclusively here. (Technically
\nspeaking, the call-backs for a short moment run on a thread-pool thread, but
\nlet\u2019s ignore that for now.) Yes, we\u2019re async, but nothing so far is really
\nhappening in parallel. Up to now, this is more like a clever ochestrated relay
\nrace, where the baton is so seemlessly passed to the next respective runner,
\nthat there simply are no hangs or blocks.<\/p>\n

But an async method can be called from a different thread at any time. And if we
\ndid this currently in our sample like this\u2026<\/p>\n

private async Task RunDisplayLoopAsyncV2()
\n {
\n \/\/ When we update the time, the method will also wait 75 ms asynchronously.
\n _sevenSegmentTimer.UpdateDelay = 75;<\/p>\n

\/\/ Let’s kick-off a dedicated task for the loop.
\n await Task.Run(ActualDisplayLoopAsync);<\/p>\n

\/\/ Local function, which represents the actual loop.
\n async Task ActualDisplayLoopAsync()
\n {
\n while (true)
\n {
\n \/\/ We update and then wait for the delay.
\n \/\/ In the meantime, the Windows message loop can process other messages,
\n \/\/ so the app remains responsive.
\n await _sevenSegmentTimer.UpdateTimeAndDelayAsync(
\n time: TimeOnly.FromDateTime(DateTime.Now));
\n }
\n }
\n }<\/p>\n

then\u2026<\/p>\n\n

The trickiness of InvokeAsync\u2019s overload resolution<\/h3>\n

So, as we learned earlier, this is an easy one to resolve, right? We\u2019re just
\nusing InvokeAsync to call our local function ActualDisplayLoopAsync, and
\nthen we\u2019re good. So, let\u2019s do that. Let\u2019s get the Task that is returned by
\nInvokeAsync and pass that to Task.Run. Easy-peasy.<\/p>\n\n

Well \u2013 that doesn\u2019t look so good. We got 2 issues. First, as mentioned before,
\nwe\u2019re trying to invoke a method returning a Task without a cancellation token.
\nInvokeAsync is warning us that we are setting up a fire-and-forget in this
\ncase, which cannot be internally awaited. And the second issue is not only a
\nwarning, it is an error. InvokeAsync is returning a Task, and we of course
\ncannot pass that to Task.Run. We can only pass an Action or a Func
\nreturning<\/em> a Task, but surely not a Task itself. But, what we can do, is
\njust converting this line into another local function, so from this\u2026<\/p>\n

\/\/ Doesn’t work. InvokeAsync wants a cancellation token, and we can’t pass Task.Run a task.
\nvar invokeTask = this.InvokeAsync(ActualDisplayLoopAsync);<\/p>\n

\/\/ Let’s kick-off a dedicated task for the loop.
\nawait Task.Run(invokeTask);<\/p>\n

\/\/ Local function, which represents the actual loop.
\nasync Task ActualDisplayLoopAsync(CancellationToken cancellation)<\/p>\n

to this:<\/p>\n

\/\/ This is a local function now, calling the actual loop on the UI Thread.
\nTask InvokeTask() => this.InvokeAsync(ActualDisplayLoopAsync, CancellationToken.None);<\/p>\n

await Task.Run(InvokeTask);<\/p>\n

async ValueTask ActualDisplayLoopAsync(CancellationToken cancellation=default)
\n…<\/p>\n

And that works like a charm now!<\/p>\n

Parallelizing for Performance or targeted code flow<\/h2>\n

Our 7-segment control has another neat trick up its sleeve: a fading animation
\nfor the separator columns. We can use this feature as follows:<\/p>\n

private async Task RunDisplayLoopAsyncV4()
\n {
\n while (true)
\n {
\n \/\/ We also have methods to fade the separators in and out!
\n \/\/ Note: There is no need to invoke these methods on the UI thread,
\n \/\/ because we can safely set the color for a label from any thread.
\n await _sevenSegmentTimer.FadeSeparatorsInAsync().ConfigureAwait(false);
\n await _sevenSegmentTimer.FadeSeparatorsOutAsync().ConfigureAwait(false);
\n }
\n }<\/p>\n

When we run this, it looks like this:<\/p>\n\n

However, there\u2019s a challenge: How can we set up our code flow so that the
\nrunning clock and the fading separators are invoked in parallel, all within a
\ncontinuous loop?<\/p>\n

To achieve this, we can leverage Task-based parallelism. The idea is to:<\/p>\n

Run both the clock update and the separator fading simultaneously:<\/strong> We execute
\nboth tasks asynchronously and wait for them to complete.
\nHandle differing task durations gracefully:<\/strong> Since the clock update and fading
\nanimations might take different amounts of time, we use Task.WhenAny to
\nensure the faster task doesn\u2019t delay the slower one.
\nReset completed tasks:<\/strong> Once a task completes, we reset it to null so the next
\niteration can start it anew.<\/p>\n

And the result is this:<\/p>\n

private async Task RunDisplayLoopAsyncV6()
\n {
\n Task? uiUpdateTask = null;
\n Task? separatorFadingTask = null;<\/p>\n

while (true)
\n {
\n async Task FadeInFadeOutAsync(CancellationToken cancellation)
\n {
\n await _sevenSegmentTimer.FadeSeparatorsInAsync(cancellation).ConfigureAwait(false);
\n await _sevenSegmentTimer.FadeSeparatorsOutAsync(cancellation).ConfigureAwait(false);
\n }<\/p>\n

uiUpdateTask ??= _sevenSegmentTimer.UpdateTimeAndDelayAsync(
\n time: TimeOnly.FromDateTime(DateTime.Now),
\n cancellation: _formCloseCancellation.Token);<\/p>\n

separatorFadingTask ??= FadeInFadeOutAsync(_formCloseCancellation.Token);
\n Task completedOrCancelledTask = await Task.WhenAny(separatorFadingTask, uiUpdateTask);<\/p>\n

if (completedOrCancelledTask.IsCanceled)
\n {
\n break;
\n }<\/p>\n

if (completedOrCancelledTask == uiUpdateTask)
\n {
\n uiUpdateTask = null;
\n }
\n else
\n {
\n separatorFadingTask = null;
\n }
\n }
\n }<\/p>\n

protected override void OnFormClosing(FormClosingEventArgs e)
\n {
\n base.OnFormClosing(e);
\n _formCloseCancellation.Cancel();
\n }<\/p>\n

And this. And you can see in this animated GIF, that the UI really stays
\nresponsive all the time, because the window can be smoothly dragged around with
\nthe mouse.<\/p>\n\n

Summary<\/h2>\n

With these new async APIs, .NET 9 brings advanced capabilities to WinForms,
\nmaking it easier to work with asynchronous UI operations. While some APIs, like
\nControl.InvokeAsync, are ready for production, experimental APIs for Form and
\nDialog management open up exciting possibilities for responsive UI development.<\/p>\n

You can find the sample code of this blog post in our
\nExtensibility-Repo<\/a>
\nin the respective Samples
\nsubfolder<\/a>.<\/p>\n

Explore the potential of async programming in WinForms with .NET 9, and be sure
\nto test out the experimental features in non-critical projects. As always, your
\nfeedback is invaluable, and we look forward to hearing how these new async
\ncapabilities enhance your development process!<\/p>\n

And, as always: Happy Coding!<\/p>\n

The post Invoking Async Power: What Awaits WinForms in .NET 9<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

As .NET continues to evolve, so do the tools available to WinForms developers, enabling more efficient and responsive applications. With […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-1519","post","type-post","status-publish","format-standard","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1519","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1519"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1519\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1519"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1519"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1519"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}