It's an old VB developer trick, but it also works quite well in .NET: to present responsive WinForms interfaces, do most of your heavy lifting in the first Paint event, rather than in the Load event. I've seen many naive WinForm developers perform database queries and other heavyweight operations in the Form Load event, which absolutely kills perceived performance-- the form doesn't even display until all the work is done! It's much better to render part of the form first so the user gets immediate visual feedback, beyond an hourglass cursor, that stuff is happening.
DoEvents is really bad. You can use a progress bar or some other method to let the user know what is going on. DoEvents lets other events execute out of order and can really ruin your day
This is such a basic (ewwwe a pun)thing that it saddens me that so many âprogrammersâ donât get it⌠If you understand your own program flow, if you KNOW HOW YOUR CODE WORKS, then DoEvents is not only fine, but itâs brilliant and you will have no problems.
If you are one of the many-and-growing who donât really even understand your own programâs flow (cough 90% open source cough), you should not only not use DoEvents, but you shouldnât use delegation or mutithreading either because you arenât a programmer , you are a voodoo practitionerâŚ
I know you read in that it was âbadâ on a blog or a magazine, or a great book, but they should have to caviat that with ââŚif you have no idea what your really doingâŚâ
It may be because I am relatively new to all this, but I struggle to see what all the fuss is about.
As I see it, .NET 2.0 programmers have three choices:
(1) Use Application.DoEvents()
(2) Use a threading model of your choice
(3) Use the BackgroundWorker class
Surely they all have the same issue: Your application needs to be written carefully, and, in particular, you need to disable certain user controls before you start a long-running process, so that the application doesnât get its knickers in a twist.
All three methods require care - and I canât see that one is massively better than any other.
I agree with Daniel - itâs just a matter of knowing how your application works. Any strong preference for one method over the other seems to me to be rather evangelical rather than practical.
I will be using the BackgroundWorker class in my next application. I will be using it purely because I want to gain experience with the various practices in .NET. I have a feeling that using Application.DoEvents() would be much simpler, and make no difference whatsover to the efficiency, maintainability and user-experience of the application.
Perhaps the advantages or disadvantages of each approach becomes more apparent in long, sprawling programs?
There is only one case where I really had to use Application.DoEvent().
Scenario: A thread is processing incoming data and post it (via BeginInvoke) to the UI thread for display. At some point, you want to terminate properly both data gathering and data display processes.
The thing is, depending on the system load, you might have no idea how many BeginInvoke calls need to be processed. Assuming that your data gathering thread is dead, how could you be sure that no more BeginInvoke calls remains to be processed? Simply call Application.DoEvent(), this will get rid of every BeginInvoke calls still in the queue. There is no other ways.
Donât tell me to switch from BeginInvoke to Invoke, in some case you simply canât. Our only hope in that case is that Microsoft NEVER remove Application.DoEvent(). Quickly think of it, Iâm pretty sure that the only scenario where this is really needed.
In brief, when you want to be sure that no more BeginInvoke calls launched from a dead thread remains to be done, call Application.DoEvent().
There is always people who will feel superior to put in practice âtoughâ or âmachoâ programming techniques, wasting time âand clients moneyâ using something that later will bring bigger headaches (threading) for something that can be solved the easy way.
Dan Tohatan is wrong, I agree with the ârefreshâ comment, the way to make the Interface
display properly while precessing something long in the loop is to call the refresh method in the form (if you add a progress bar is even better). so that if you are switching screens to other apps and coming back to check the progress you will still see something and not just a white square.
The DoEvents is used ONLY FOR the PURPOSE to allow the user to actually click on some control in the form while processing (best example: a cancel button), so DOEVENTS is really very useful for what it was intendend, now if people use it the wrong way thatâs another story⌠I can see many related posts âDoEvents Considered Harmfulâ
I started out as a Java programmer personally - threading there is - in my humble opinion - much simpler where your able to simply inherit from the thread object then use a nice simple set of flags in the new object and some nice accessor methods to control the thread flow.
However that said I really donât see what the big fuss about using thread in .NET is either. Generally good OO program doesnât INCLUDE much - if any shared memory and simply adhering to good coding procedures keeps your code clean enough for threading to be safe.
That said I concede after reading this that App.DoEvents certainly has its place in the programmers arsenal. Never throw away a perfectly good tool.
Do you think that open source programmers donât know the programâs flow? And what do you think about the fact that Linux (caution, an open source operating system) donât need to accommodate an obscure DoEvents() method? Is a possible answer the fact that in Linux the XServers are clearly uncoupled from XClients through the XProtocol?
In other words: Is it possible, that MS Windows is made by many-and-growing programmers (as you said) or why is there a need for a such dirty method like âDoEvents()â (- DoEvents() WILL break your programâs flow)?
I have no preference⌠please be careful when drawing comparisons.
DoEvents is very useful! Itâs certainly not evil⌠unless youâre the soft of programmer who gets confused easily⌠in which case you should probably go play with some crayons or revert to VB6