Event's code runs to completion before another event's code is entered?

  • Thread starter Thread starter Academia
  • Start date Start date
A

Academia

If the user types into the TextBox of a combobox it works OK. But if he hold
a key down so the letter repeats quickly the code runs into trouble.

My questions are:

Is it true that an event's code is normally run to completion before another
event's code is entered (KeyUp in my case)?

If that is true and there are exceptions that let another event start do
they include:

When DoEvents is executed?
When File I/O is executed?

Any others...

I don't believe there is a DoEvents in the executed code but there is
definitely file I/O.

It's a large program and difficult to find things out by experimenting. If I
had the answers to the above it would help much.



Thanks
 
Academia said:
If the user types into the TextBox of a combobox it works OK. But if he hold
a key down so the letter repeats quickly the code runs into trouble.
Click to expand...

What kind of trouble?
My questions are:

Is it true that an event's code is normally run to completion before another
event's code is entered (KeyUp in my case)?
Click to expand...

The events are queued in the message queue of the application, and the
queue is handled in the main thread, one message at a time.
If that is true and there are exceptions that let another event start do
they include:

When DoEvents is executed?
Click to expand...

Yes, the DoEvents call will consume any available messages from the queue.
When File I/O is executed?
No.

Any others...
Click to expand...

No.
 
I just erassed the answer I was typying because something occured to me.

Holding a key down proprably generates many KeyPreses but no KeyUp event
until the key is released.

Not sure what other events are raised, but maybe TextChanged and others are
happening without the KeyUp I expected per input character and coded for.

I'll have to go look at the code.

Any way I can run the code and see which events were raised between the
KeyPress and the KeyUp events?

thanks

Göran Andersson said:
What kind of trouble?


The events are queued in the message queue of the application, and the
queue is handled in the main thread, one message at a time.


Yes, the DoEvents call will consume any available messages from the queue.


No.
Click to expand...

It must release the CPU while waiting for the i/o to complete.
 
Rather than looking at the code, you really need to do some reading of the
documentation relating to the Key... events. F1 is your friend for this.

When you 'press' a key there are three distinct stages.

The first is when you depress the key.

The second is when you released the key.

When, and only when, the first two stages have been completed, does stage 3
occur. At his stage the key is considered to be 'pressed'.

These three stages have a direct correlation to the Key... events.

When you depress a key, the KeyDown event is raised.

When you release a key, the KeyUp event is raised.

When, and only when, you have depressed a key and then released it, the
KeyPress event is raised.

Unless you specifically raise any events in your code then there will be NO
Key... events raised between the KeyUp and KeyPress events being raised.

There will certainly NEVER be any Key... events raised between the KeyPress
and KeyUp events because the KeyPress event is NEVER raised before the KeyUp
event.


Academia said:
I just erassed the answer I was typying because something occured to me.

Holding a key down proprably generates many KeyPreses but no KeyUp event
until the key is released.

Not sure what other events are raised, but maybe TextChanged and others
are happening without the KeyUp I expected per input character and coded
for.

I'll have to go look at the code.

Any way I can run the code and see which events were raised between the
KeyPress and the KeyUp events?

thanks

Göran Andersson said:
What kind of trouble?


The events are queued in the message queue of the application, and the
queue is handled in the main thread, one message at a time.


Yes, the DoEvents call will consume any available messages from the
queue.


No.
Click to expand...

It must release the CPU while waiting for the i/o to complete.
Click to expand...
 
What about this:
<http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.keypress.aspx>
which says the sequence is:

KeyDown
KeyPress
KeyUp

Also I'm pretty sure if you hold a key down you get multiple KeyPress
events between a single pair of KeyDown / KeyUp.

Rather than looking at the code, you really need to do some reading of the
documentation relating to the Key... events. F1 is your friend for this.

When you 'press' a key there are three distinct stages.

The first is when you depress the key.

The second is when you released the key.

When, and only when, the first two stages have been completed, does stage 3
occur. At his stage the key is considered to be 'pressed'.

These three stages have a direct correlation to the Key... events.

When you depress a key, the KeyDown event is raised.

When you release a key, the KeyUp event is raised.

When, and only when, you have depressed a key and then released it, the
KeyPress event is raised.

Unless you specifically raise any events in your code then there will be NO
Key... events raised between the KeyUp and KeyPress events being raised.

There will certainly NEVER be any Key... events raised between the KeyPress
and KeyUp events because the KeyPress event is NEVER raised before the KeyUp
event.
Click to expand...
 
Please disregard my earlier post.

One of those blonde moments :)


Stephany Young said:
Rather than looking at the code, you really need to do some reading of the
documentation relating to the Key... events. F1 is your friend for this.

When you 'press' a key there are three distinct stages.

The first is when you depress the key.

The second is when you released the key.

When, and only when, the first two stages have been completed, does stage
3 occur. At his stage the key is considered to be 'pressed'.

These three stages have a direct correlation to the Key... events.

When you depress a key, the KeyDown event is raised.

When you release a key, the KeyUp event is raised.

When, and only when, you have depressed a key and then released it, the
KeyPress event is raised.

Unless you specifically raise any events in your code then there will be
NO Key... events raised between the KeyUp and KeyPress events being
raised.

There will certainly NEVER be any Key... events raised between the
KeyPress and KeyUp events because the KeyPress event is NEVER raised
before the KeyUp event.
Click to expand...
 
Thanks but as I said below I think it's

KeyPress then KeyUp

check help for "Control.KeyUp Event"

Stephany Young said:
Rather than looking at the code, you really need to do some reading of the
documentation relating to the Key... events. F1 is your friend for this.

When you 'press' a key there are three distinct stages.

The first is when you depress the key.

The second is when you released the key.

When, and only when, the first two stages have been completed, does stage
3 occur. At his stage the key is considered to be 'pressed'.

These three stages have a direct correlation to the Key... events.

When you depress a key, the KeyDown event is raised.

When you release a key, the KeyUp event is raised.

When, and only when, you have depressed a key and then released it, the
KeyPress event is raised.

Unless you specifically raise any events in your code then there will be
NO Key... events raised between the KeyUp and KeyPress events being
raised.

There will certainly NEVER be any Key... events raised between the
KeyPress and KeyUp events because the KeyPress event is NEVER raised
before the KeyUp event.
Click to expand...
 
Academia said:
Holding a key down proprably generates many KeyPreses but no KeyUp event
until the key is released.
Correct.

Not sure what other events are raised, but maybe TextChanged and others are
happening without the KeyUp I expected per input character and coded for.
Click to expand...

The key events are put in the same queue as other events, and are
handled by the same message pump. If a keypress for example changes the
apperance of a control, the messages that tells the control to change
itself is added to the message queue.
Any way I can run the code and see which events were raised between the
KeyPress and the KeyUp events?
Click to expand...

You could add Debug.Write statements to the event handlers, so that you
can track what's happening. (Debugging and putting break points in the
event handlers might not work very well, as you interfer so much on the
event handling process that way.)
It must release the CPU while waiting for the i/o to complete.
Click to expand...

Yes, but not to the thread that called the I/O operation. Whatever the
computer does while waiting for the I/O, it's not consuming event
messages in your application.
 
Back
Top