Printable View
A co-worker is telling me that VB’s DoEvents should never be used in a VB event driven application. I also worked at a previous job where we weren’t allowed to use DoEvents at all.
In both cases no one can give me an explanation as to why DoEvents is bad. I use them inside of loops, standard EXE apps, to prevent the app from appearing locked up. I have never witnessed any adverse behavior from the DoEvents function.
Does anyone know of any concrete reason why VB 6’s DoEvents should NOT be used?
Dino,
The only reason I can think of is that DoEvents relinquishes control back to the OS ... It is usually a good thing unless the app is timing critical (in which case c/c++ should be used instead) which could be thrown off ... Generally what you have observed is good. VB needs DoEvent calls to mak long processes seem like the app is not locked up.
This could be an interesting discussion. First, I would have to guess that those who don't allow its use are looking at it from the standpoint "if a function is so intense that DoEvents is required, then the function must be faulty". Obviously, this is incorrect. However, one should not rely on DoEvents to save the day every time a function is too processor intensive. One thing I like to do is use Whatever.Refresh instead. This will give time for other stuff in the app to update, but not take more time that necessary away from the app. DoEvents allows all apps to get updated, which will take longer to complete.
Many windows functions and vb functions will hog system time just as any For...Next loop can. For instance, the Replace() function will pause the app until it returns, and a loop serving the same function will do much the same thing, although it will probably take longer. If responsiveness is why some don't like the need for DoEvents, then they would also dislike just about every function there is. Certainly, most will not cause a noticable pause, but it's a pause just the same. Using DoEvents in a loop is not bad programming, but it may be seen by some as a fix for it, so they think if you need it, then the code is bad. Anyone who thinks this simply doesn't understand how the computer operates. A single processor can only do one thing at a time. Windows simply "fakes" multitasking by time sharing.
One important note here is that an app should never be in an endless loop, such that DoEvents is necessary to keep the system responsive. This is most likely what they want to avoid. Many people are quick to use a timer when they want some function to keep executing. While it beats an endless loop, it is not always as good a solution as vb can manage.
When efficiency is top priority, vb should not be used anyway. DoEvents may not be bad, but it is not a cure-all, and shouldn't be used in place of good programming practices. Every function takes a certain time to complete. DoEvents takes time from the app as well. I don't like having to use DoEvents, and will avoid it when it makes sense to do so, but I do find times when it seems to be the best overall way out. Multithreading would help greatly in reducing the need for DoEvents, but that's another story...
...doevent was great. Then I met one who told me: "if you're using DoEvents, you're loosing events-control".
Well, he did not meant you can control any event, but he was saying: "you're flushing all events, and you cannot know what is happening meanwhile - for example - you're updating a recordset in batch mode".
This last was part odf the matter: he used only UpdateBatch, and a series of Ocx he developed to gain a kind of binding controls. Events all around were fundamentals, and he said:"If I really need something that is a kind of asyncronous, I prefer to use a timer".
I am still uncertain, but I am thinking about using a timer instead...
Cimperiali
What you are saying seems like the opposite of multithreading, so that you control each and every event in a specified sequence. This can be an issue for something like when the user clicks a button during a loop with DoEvents. Here is a simple example of this:
This will allow the loop to be interrupted, and could also change variables, effecting the loop. However, take out the DoEvents, and use the Refresh line so that the button can't be clicked until the loop is done. The downside is that the user thinks the button isn't responding, so it is probably a good idea to disable the button.Code:Private Sub Command1_Click()
Dim A$, I
For I = 0 To 100000
A = A & "A"
Label1 = I
DoEvents
'Me.Refresh 'or Label1.Refresh
Next
Debug.Print "done"
End Sub
Private Sub Command2_Click()
MsgBox "hello"
End Sub
Also, the less you refresh, the faster the loop will execute, so Me.Refresh is faster than DoEvents, and Label1.Refresh is faster than refreshing the entire form.
I was also told that DoEvents is a (bad) solution to poor programming.
My previous employer's old products used lots of timers and lots of DoEvents. They were large programs and merely looking at these timers and DoEvents did very nasty and unexpected things in so far as messing with events and the order in which fired etc. The replacement products avoided them at all costs, mainly because any development / further development / bug fixing etc to them would be hindered by and/or interfere with them, and I agreed with this philosophy.
However, before one of you points it out to me, I realise that at least one of the answers I have provided on this forum has included use of DoEvents. Also, my Thesis (yep, coded using VB) required it for display purposes while some very busy loops were in progress - though I would design the program oh so very differently if I were to do it again...
To conclude, I would use DoEvents only as a last resort, when all other avenue's have been persued without success - but there are plenty of avenue's...
I hope i am not out of subject, but how is possible to tell VB to run events for a single object, like a command button, inside a continuously do..loop? This is usefull for example if we want to make a long process but with the possibility to interrupt it via a button placed on a visible form. Thanks.
Wizbang, as you say a Timer is a good solution for keep executing functions, instead of an endless loop. I've noticed that Vb cant respond to a timer event in less than 100 milliseconds, maybe much more, even on a Pentium-4 machine and of course even if you set the interval property equal to 1. This is fatal for apps built for making animation, moving graphics etc, i think. Just a notice.
Dino,
You are right to the point that the DoEvents is critical inside an event driven application, but it does not mean that it is not advisable though not to be used anymore. No, you just have to do some timing when to use the function, only when the event was triggered by the main thread. But on the other hand, no choide:D, you have to use definitely the timer because the function may always respond (flushing the events) to the queued events (caused by a different thread) which in turns the synchronization and completion of the event may be destroyed.
Hi all,
I agree with the sentiment that a need to use DoEvents can sometimes mean your program could be written in a better way, but this is not always the case.
I have used DoEvents inside intensive loops so that Windows "appears" :D to operate normally, but I would not usually do such things when other critical events in my app are taking place, and might set flags to inform other events that I was doing something intensive and to hold off on what you were doing until it was done (setting priorities if you like).
Other times, I have found it a neccessity to use DoEvents, especially when you are dealing with processes outside of your own VB application. I have had many instances where a DoEvents was needed to allow values elsewhere in the system to be updated before continuing with the next line of code which was dependant on the API calls that I had just made (especially API calls that involve updating the display in some way or file I/O access), and especially on slower systems.
I guess it depends on what your application is doing, and how much it interacts with the system (as DoEvents momentarily releases control back to the system to give other events and processes a chance to complete). While you could say that needing to use DoEvents could suggest your code is written badly, having an application that cant deal with using DoEvents could also equally suggest a badly written application :)
Cheers.
Hi Friends,
This is good disc going on.
I use Do Events in my projects.
Case 1:
Suppose I am loading some form and then calling some data to be load into grid, listviews, text box etc.
Then I show the form and fire Do Events so Form is showed.
So User get that form is loaded.
Then I call data to be loaded,
1) Show data into all text box
Doevents
2) Load List Box, Combo Box
Doevents
3) Load Grids
Doevnents
4) Load List view and other controls
Doevnets
So User can see that Data is coming, It helps mostly on Slow pc having P1, Ram 32 MB
---------------------------------------------
I have posted some problems, please see it, and help me.
dtv
When you need a timer with better resolution, you can use a timer class and set the process priority as needed.
Started with one kilobyte of capacity (sinclair spectrum), used to program turbo pascal like ****, recently i discover that the class modules of vb is similar to dos' turbo pascal 6.0 objects declarations... (...), i think anyone of us has enough room for more knowledge and its not possible to put all the solutions in a simple human brain. I think thats what a forum is, thanks Wizbang.