Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to suspend code till Activex event is handled
- Thread starter fossx
- Start date
I'm not sure I understand your requirement, but we'll see.
You could try tying your DoEvents to a timer rather than a loop. That way you can control the number of times per second DoEvents gets executed.
This thread thread222-1285729 will give you a basic technique that might work better. I'd use the IsProcessRunning part of this along with a Timer function. If you want to explore this idea further, doing a search in the VB5/6 forum for "IsProcessRunning" will give more examples from Hypetia.
HTH
Bob
You could try tying your DoEvents to a timer rather than a loop. That way you can control the number of times per second DoEvents gets executed.
This thread thread222-1285729 will give you a basic technique that might work better. I'd use the IsProcessRunning part of this along with a Timer function. If you want to explore this idea further, doing a search in the VB5/6 forum for "IsProcessRunning" will give more examples from Hypetia.
HTH
Bob
dilettante
MIS
My guess would be that this user is trying to force logic on a VB form to run as straight-line code instead of programming against the form's event model. Thus use of a Timer's events would probably defeat his purpose.
While there are exceptions to every rule, the basic principal I follow with DoEvents() is don't. The major exception is to allow UI updates to take place during lengthy processing within an event handler: things like progress bar updates, status line message display, and command button enable/disable or caption changes. There are other exceptions too of course but most of them occur within the logic of a UserControl or Class that is processing local events and wants to raise an event to its container and allow it to be handled right away.
Using DoEvents() within an event handler always presents the potential of unanticpated re-entrancy. I see this most often with code handling Winsock control events, where it can lead to problems ranging from received data fragments being processed out of sequence to stack overflows.
While there are exceptions to every rule, the basic principal I follow with DoEvents() is don't. The major exception is to allow UI updates to take place during lengthy processing within an event handler: things like progress bar updates, status line message display, and command button enable/disable or caption changes. There are other exceptions too of course but most of them occur within the logic of a UserControl or Class that is processing local events and wants to raise an event to its container and allow it to be handled right away.
Using DoEvents() within an event handler always presents the potential of unanticpated re-entrancy. I see this most often with code handling Winsock control events, where it can lead to problems ranging from received data fragments being processed out of sequence to stack overflows.
- Status
Similar threads
- Locked
- Question
