I need an explanation on this snippet of VB6 code

Hi Experts,

I have this small piece of code that I need explained.

Code:

---

Do While receiveMessages
    DoEvents
Loop

---

receiveMessages is a boolean variable.

I have a user control that embeds into an existing app via implementation of interface.

When my user control is embedded, the textbox in my user control could not respond to keyboard navigation and keyboard commands for copy and paste.
In my investigation I found out that the usercontrol form receives the keyboard commands but not the textbox. That is, the textbox does not respond to WM_KEYUP events for arrow keys and ctrl or shift keys.
Somehow the parent must be doing some stuff which I don't know.

Having the above code somewhere in my user control fixes the textbox problem.

My question is, what is DoEvents in a Loop doing?
Does it somehow retain control to my user control and not the parent form where my user control is embedded?

I really have no idea why this code is fixing the issue. Must be some underlying reason with the event handling and threading.

Before Win95, Windows could only do one thing at a time. This meant that events like mouse clicks and other user input could only be serviced in order, like everything else, even if they were in another program. A macro also has to be serviced in order, and while it was running, the code that processed events could not run. To solve this, the DoEvents command allowed Windows to take a break from the macro, process any pending events (even in other programs), and then return control to the macro. It is still somewhat useful today because while Windows can handle the events without worrying about a macro bogging it down, an individual program like Access is still limited.

In the modern era, DoEvents is a relic of the old Windows that will slowly disappear as things like .NET supplant VBA and the old event processing infrastructure.

VB is not multithreaded. Events/procedure/stack processing is LIFO... so while your still in a procedure other events, e.g. keyboard events, messages are not processed and are queued. DoEvents within procedure allows windows messages in queue to be processed before resuming next statement in procedure.

Hi koolskid, I could not rate you for now on your reply.

But so you know I really appreciate it! :wave:

So what are the possible scenarios that keyboard events for one control gets wiped out or not processed?

Is it some other call that somehow polls these events and then removes it from the queue?

Or is it a windows fail safe where a windows command can only stay within the queue for so long?

Right now I am assuming that some other process somehow inspects all keyboard events and removes it from the queue. But I'm probably wrong.

Windows messages are handled by the operating system, along with its routing, queung per window, cascade to elements within window, etc.

DoEvents in action
Without DoEvents only part of the the form is hidden.

Code:

---

Me.Visible = False
'DoEvents
Sleep 1800
Me.Visible = True

---

Work correctly when DoEvents is added

In .NET its still in existance.

Code:

---

Application.DoEvents()

---

Quote:

---

Originally Posted by oceanebelle

Hi koolskid, I could not rate you for now on your reply.

But so you know I really appreciate it! :wave:

---

Thats ok... How about an e-burger :D

Damn I am very hungry right now....