winforms
winforms copied to clipboard
dotnet
What's new with async support for WinForms event handlers?
I'm sure I'm not the first to ask this but is there anything new with regards to WinForms event handlers implementing async?
Basically, since everything is basically done in event handlers with WinForms, the question is can I use async/await at all?
Looks like the old workaround is to return void instead of Task. But I know this can cause problems.
I know the WinForms engine was recently built for .NET 5.0/6.0. Was any thought given to this?
We have planned this for the .NET 7 timeframe, but we also need to complete some urgent new Designer functionality, so we may reprioritize or not tackle all of those. As always: Help for from the community is highly appriciated!
https://github.com/dotnet/winforms/issues/4631 https://github.com/dotnet/winforms/issues/5917 https://github.com/dotnet/winforms/issues/5918
If you have other things in mind, you'd find important, please file an issue!
@KlausLoeffelmann Thanks. I know WinForms is not Microsoft's highest priority. I've been working with WinForms/.NET 6.0 for about a week. My biggest complaint is that the designer is a bit slow and buggy (and a little unstable) . Get a lot of errors and even lost a bit of work. Will file an issue if I get something repeatable.
Otherwise, looking forward to potential async support in .NET 7.
It has a pretty big priority... 😄
Do you mean the runtime, which should be noticeably faster than Framework, or the Designer? Without being bug-report-specific: What areas do you see slow performance?
@KlausLoeffelmann Looks like you were probably responding to me. I was mostly referring to the designer. It sometimes takes several seconds to load a form in the designer. And I crashed it more than once where either Visual Studio had to restart and/or the form became corrupt.
@SoftCircuits we've made a number of improvements in the async load of the out of process designer for .NET. Hopefully things are looking better for you.
@KlausLoeffelmann should this be duped against your API proposal issue?
Async event (handlers) would be a different beast altogether, but would definitely add to the robustness of WinForms apps. I would like to have this separately, but I am linking it. Possibly, an Async Initiative parent (epic) issue would be a good idea? @merriemcgaw ?
@SoftCircuits we've made a number of improvements in the async load of the out of process designer for .NET. Hopefully things are looking better for you.
Thanks. I'll check it out!
Basically, since everything is basically done in event handlers with WinForms, the question is can I use
async/awaitat all? Looks like the old workaround is to returnvoidinstead ofTask. But I know this can cause problems.
Sorry to insert myself in this conversation, but could you describe what you mean by "I know this can cause problems"?
AFAIK, this pattern is the way you should use async pattern in winforms, as I have done multiple times, and I have read nothing wrong about that.
Well, depending events can be problematic, since async void are fire and forgets. So, if you have for example a Processing and a Processed event, where Processing is supposed to be blocked on the consumer-side, you might be ending up with firing both in succession, since Processing would not be (a)waiting for the consumer-side to be finished, since it is a fire and forget. So, invoking that event should be done asynchronously and awaited.
Will async event handlers wait for each other to finish running, and skip remaining handlers when any handler throws an exception, just like synchronous event handlers? This would require looping over Delegate.GetInvocationList and awaiting each handler before invoking the next.
In contrast, multiple handlers with today's async void can't wait for each other to complete, and an exception thrown in one handler doesn't skip other handlers.
