Possible Dangers Application.DoEvents

Question

0.00/5 (No votes)

See more:

Hi,

I have used DoEvents in VB6 to free up multi-tasking and get stuff (like comms) done. The C# equlivalent is Application.DoEvents, I would like to know if it is viewed as bad practice with multi-core PC's (along with Thread.Sleep()). As I have only used VB6 many moons ago in Windows 2000. I have searched the web and found some conflicting info.

Thanks
Glenn

Posted 2-Feb-12 22:27pm

glennPattonWork3

Add a Solution

3 solutions

Solution 4

The only time you should be using DoEvents is if you want to be in a tight processing loop and essentially managing the message queue yourself. If you're writing an interactive game this can be legitimate. Generally, for normal applications, you should thread.

Posted 3-Feb-12 5:02am

BobJanova

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2012-02-02T22:47:00

Solution 1

Yes.

If your application needs DoEvents, then it is badly designed - you should not be doing anything in your UI thread which takes significant amounts of time (and this applies to your VB code as well as PC). You should move that code onto a separate Thread - look at using a BackgroundWorker class[^]. It's pretty simple, and the link contains an example.

Posted 2-Feb-12 22:47pm

OriginalGriff

Comments

glennPattonWork3 3-Feb-12 4:58am

Thanks for that! (its a typical "you have almost done the code already just add this command", and then it snowballs). The BackgroundWorker class looks interesting I will start to have a play, it's Friday!

OriginalGriff 3-Feb-12 5:03am

You're welcome!
It's pretty easy to use, particularly if your code can be extracted easily - the only pain is that you can only update UI components from the thread they were created on, which means using Invoke. But that isn't complicated either! :laugh:

Sergey Alexandrovich Kryukov 3-Feb-12 5:02am

Of course it is bad. Not explained, but explanation can be pretty long...
I would prefer if you mentioned all 3 ways of getting a thread (Thread constructor and thread pool).
My 5 anyway.
--SA

Sergey Alexandrovich Kryukov 3-Feb-12 5:05am

By the way, Jaganathan provided a link to the interesting discussion.
--SA

Jaganathan Bantheswaran · Accepted Answer · 2012-02-02T22:59:00

Solution 2

Hi,

Couple of nice post by Jeff Atwood will clear your confliction

Posted 2-Feb-12 22:59pm

Jaganathan Bantheswaran

Comments

Sergey Alexandrovich Kryukov 3-Feb-12 5:05am

Well good to know, my 5, but I disagree with those Microsoft representative who says that DoEvent sometimes is better than thread, in simple cases. Well, maybe very rarely.
--SA

BobJanova 3-Feb-12 11:01am

Bear in mind that this article is 6 years old, and there is stuff (notably TPL but also better BackgroundWorker support) that makes the threaded approach easier.