Suggestion to use My.Application.DoEvents is irresponsible.

[Darkicorn]

It is irresponsible to show an example with My.Application.DoEvents - at the very least the note saying "don't use it" should come before the example. Preferably the example should be re-written to eliminate it. (It's an issue that's been going on for more than twenty years, so it might as well be fixed now.)

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 49d0445d-5b7f-d2d8-5fa6-8301de72e38f
• Version Independent ID: e827f1d2-f1a0-ecf9-5e7a-866fd3327012
• Content: RaiseEvent Statement - Visual Basic
• Content Source: docs/visual-basic/language-reference/statements/raiseevent-statement.md
• Product: dotnet-visualbasic
• GitHub Login: @KathleenDollard
• Microsoft Alias: kdollard

[KlausLoeffelmann]

Hey @Darkicorn,

thanks for addressing this.
I am not sure what exact scenario you have in mind, but we might consider adding some additional info to Application.DoEvents (@merriemcgaw, @adegeo FYI)

A somewhat problematic scenario can occur, when there is a long-running task which runs on the UI thread, probably triggered by a typical WinForms ButtonClick event handler method (or the alike):

Now, this of course blocks the further processing of the UI-Thread. And that means after a couple of seconds, the App becomes unresponsive, and yes, that's bad. So, what folks often do to mitigate, is this:

And with that they are introducing a potential and unintended recursion. Users of the app may hit the button repeatedly. And with that, they are queuing in more the button click events, which are (indirectly) called from the still executing button click event handler method, and so on, and so on.

This is certainly an improvable design.

Things to mitigate that:

• Disabling the button in this case at the beginning of the loop, so it cannot be engaged repeatedly.
• Use a background worker for executing the long-running task.
• Use async/await to handle long-running tasks asynchronously.

In all the cases, the UI controls would need to be guarded against multiple clicks.
We should consider putting those suggestions in the docs.

@Darkicorn, did you have other scenarios in mind?

Thanks,

Klaus

[BillWagner]

Thanks for the added clarification @KlausLoeffelmann

I'll add this to our backlog as an enhancement. I'll also add the "help wanted" label in case anyone wants to submit a PR before we update it.

[Adi9235]

Hey @BillWagner can I work on this issue ? It would be great if you could elaborate on how to fix this issue.

[BillWagner]

Hi @Adi9235

Thanks for volunteering to work on this. @KlausLoeffelmann 's comment #34917 (comment) provides the background to address this. The core problem is that Application.DoEvents() processes additional messages. Unless you take some mitigating actions (like disabling the button), a user can trigger repeated events for the same command.

[adegeo]

I don't agree with

It is irresponsible to show an example with My.Application.DoEvents

But I do agree with

Preferably the example should be re-written to eliminate it

The example in the article isn't well written. And the headings seem odd. Example 1 doesn't actuallk contain an example. Further, there are details that should be in the main portion of the article, such as where you can declare events and use RaiseEvents statement.

Another problem is that it's written in the context of Windows Forms and not just in the context of VB the language. The UI stack doesn't matter when talking about the RaiseEvents statement. The example isn't useful to someone who is using WPF and has never touched WinForms. I would opt for an example that is just a simple console app.

[Adi9235]

I will try to fix this issue and will make the PR soon

[KlausLoeffelmann]

Definitely +1 to what @adegeo said. We should see though, that we add this warning where it actually belongs, so in the WinForms app space. But I guess it's not too much of a high priority.

[adegeo]

Definitely +1 to what @adegeo said. We should see though, that we add this warning where it actually belongs, so in the WinForms app space. But I guess it's not too much of a high priority.

Yes, the WinForms docs should have something about DoEvents, the caveats, dangers, and proper scenarios.

Here is a good thread about it: https://stackoverflow.com/questions/11352301/how-to-use-doevents-without-being-evil

I created this issue to track it: dotnet/docs-desktop#1647