When would you execute doevents more than once?

[stanhilliard]

I have seen examples where doevents is looped or repeated several times. Yet the explanation of doevents is that it allows all events to finish execution.

For what purpose would you need doevents to execute more that once?

[SamT]

Why not?

Seriously: Why not use Do Events any time it feels like it might be handy?



Ex: A loop takes a long time and I might want to Ctrl+C it. Do events once per loop.

Ex: This Appl, (Word, Excel, etc) it interfacing with another running Appl. Do Events.

Ex: Waiting for a response from outside the Appl.
While no Response
Do Events
Loop

Ex: T/Sing Code that randomly breaks. Do Events

Ex: Possible timing issue. Do Events

Ex: Anytime you are interfacing with the internet/network at the same time any code is running. A lot of Do Events.



Windows raises an event flag whenever something outside your code needs to be done, Do Events allows Windows to do these things, It basically just 'says,' "This code will pause while you (Windows) does what needs doing."

[stanhilliard]

I can understand that it may be necessary to interrupt long running loops by giving the busy application a chance to recognize a manual brake (ctrl-scrolllock on my computer), or to manually select a different worksheet to observe it on screen. But once one doevents lets other executions finish, why wouldn't it recognize the manual interrupt? What is happening that would require something like:

For I = 1 to 100
doevents
Next I

Doesn't the first (I=1) execution clear the existing backlog so that a manual interrupt can be handled next? What would prevent that? What am I missing here?

[SamT]

For I = 1 to 100
doevents
Next I
Fixes a timing issue.

Do Events is a cheap, safe, lazy way to handle most timing issues; An alternative that I once used on a very time critical App (literally had to perform in less than 50 milliseconds,) Where a 36 cell, updated Range had to be evaluated, transformed, and the results wrote back to a worksheet, had me code a separate workbook with a dozen or so nested Class modules and each parent Class was triggered by the child Classes telling it that the child had completed its function. The first Book used Worksheet_Change to trigger the second, the second "told" the first when it was done, then the first "asked" the second for the results. Absolutely no "Do Events" but a lot of work on my part to insure that there were no timing issues.

Using a separate workbook and Class Modules took advantage of multicore processors and Hyper Threading, in an effort to increase speed of operation.