DoEvents. what is it useful for

[ragstta]

DoEvents. what is it useful for.

does it just give control back to the user ie enable controls
during some processing?

[jmcilhinney]

DoEvents will force the application to process any pending events. If you're performing a long operation and an event is raised it must wait until you finish your operation to be handled. By calling DoEvents you pause what you're doing and handle any events in the queue. Many of those events will be raised by the user's actions, like clicking a button. That's why you were under that misconception.

You should generally avoid calling DoEvents. If a situation seems like it requires it then you should think about using multithreading. Only in the most trivial cases should actually use DoEvents to keep a UI responsive during long operations.

[TTn]

Or use SendKeys.Flush

to wait for the application to process keystrokes and other operating system messages that are in the message queue. This is equivalent to calling Application.DoEvents until there are no more keys to process.

Also note, that VB60's DoEvents sleeps the thread to yield, while .NET's Application.DoEvents does not.
I prefer SendKeys.Flush which does not seem to crash, as Application.DoEvents did in some scenarios.

My SendInputToWindow class, would not work the same without SendKeys.Flush, and System.Threading.Thread.Sleep.
In fact the combined method SleepFlush is the key element, which generally mimics the old DoEvents, without being as buggy.

[robertx]

DoEvents will force the application to process any pending events. If you're performing a long operation and an event is raised it must wait until you finish your operation to be handled. By calling DoEvents you pause what you're doing and handle any events in the queue. Many of those events will be raised by the user's actions, like clicking a button. That's why you were under that misconception.

You should generally avoid calling DoEvents. If a situation seems like it requires it then you should think about using multithreading. Only in the most trivial cases should actually use DoEvents to keep a UI responsive during long operations.

The most common situation where I use DoEvents is where I have a progress bar that is incremented on each iteration of a loop. If DoEvents is not used in each iteration, the progress bar does not increment. Are you saying that there is a better way to achieve this without using DoEvents?

[phillipst]

You could refresh the form each time. That might work.

[TTn]

You could refresh the form each time. That might work.

Yes, .Refresh() would be the way to go, since DoEvents does that AND a bunch of other extra things that you dont need to do.

[jmcilhinney]

You shouldn't even refresh the form, just the progress bar.

[robertx]

When I was learning VB6, I read that DoEvents could and should be used liberally to make screens and controls appear sharply. Therefore, I have often used it routinely in my Form_Activate(d) event to ensure that controls are drawn quickly to provide a better visual experience.

Are you saying that you don't agree that DoEvents should be used liberally in this way or that the nature of DoEvents has changed in .NET such that it should no longer be used in such a way?

Is the refresh method of the progress bar better than using DoEvents?

[jmcilhinney]

Most things happen so fast in a modern app that calling DoEvents offers little to no benefit. If you do have a longer-running operation then calling DoEvents can help in certain situations. An example is if the user drags another form over yours. The problem is that if it's not needed then you're calling DoEvents repeatedly for no reason, thus making your code less efficient. As I said, if what you're doing makes a significant difference to the responsiveness of the UI then you might want to consider using multi-threading. The new BackgroundWorker makes this virtual child's play. With virtually all new processors being multi-core, now is the time start thinking seriously about how multi-threading can be used to make all apps more efficient.

[TTn]

Are my posts not getting through?
I thought I said:

Yes, .Refresh() would be the way to go,...

jmcilhinney,
Is this not what you mean?
ProgressBar1.Refresh()

robertx,

When I was learning VB6

or that the nature of DoEvents has changed in .NET

Yes, that's close enough.