how to clear keyboard buffer?

[Alex K.]

Hi all
On my form I have buttonSAVE button. The buttonSave_Click procedure looks
like this:

private void buttonSave_Click(object sender, System.EventArgs e)
{
DoSomething();
SaveObject();
MessageBox("Object saved");
}

When users use mouse to click the button, everything is fine. But there is a
problem when they use space bar on keyboard:
if you move focus (using TAB key) to SAVE button and then press space bar
two times very quickly, the save procedure successfully executes without
showing confirmation MessageBox. I guess, MessageBox does not appear on the
screen because second stroke of space bar closes it before it is drawn.
As a result, user does not confirmation that object is saved. Even worse, if
you press space bar 4 times, the object will be saved 2 times without
confirmation!

I'd like to make sure user always gets the confirmation, i.e. MessageBox
always shows and waits until user closes it explicitly, ignoring all pending
key strokes that might be in the buffer at the moment when SaveObject()
procedure ends.

I tried to call Application.DoEvents() right before MessageBox.Show, but
that resolved only part of the problem: if I hit space bar twice, I will get
eventually two MessageBoxes, but object is already saved twice when I see the
first message box! All this is extremely confusing. I'd like to avoid second
saving until user sees and aknowledges first confirmation. I think, if I
could clear the keyboard buffer before showing MessageBox (as I used to do in
MS DOS), that would resolve the problem.

Is there not-very-tricky way to do this?
Thank you

 

[Alex K.]

forgot to mention: I am using VS 2005 in XP Sp3

 

[Peter Duniho]

[...]
I'd like to make sure user always gets the confirmation, i.e. MessageBox
always shows and waits until user closes it explicitly, ignoring all pending
key strokes that might be in the buffer at the moment when SaveObject()
procedure ends.

The user _does_ always get the confirmation. They just happen to
dismiss it before it's been around long enough for them to see it.

As for clearing the keyboard buffer, no….NET doesn't have anything for
that. But even if it did, it wouldn't help. There will _always_ be a
point in time during which the user can enter input that would dismiss
the MessageBox before the user's had a chance to see it.

A better solution would be for you to implement your own modal dialog
for the purpose. It's fairly trivial to design a regular Form sub-class
that will show the information the way you want.

Once you've done that, you can include a timer in the Form, override the
OnFormClosing() method, and if the timer hasn't expired yet, cancel the
close. That will ensure that any input to close the Form sub-class
before whatever minimum time you choose has passed will be ignored.

Pete

 

[Harlan Messinger]

Hi all
On my form I have buttonSAVE button. The buttonSave_Click procedure looks
like this:

private void buttonSave_Click(object sender, System.EventArgs e)
{
DoSomething();
SaveObject();
MessageBox("Object saved");
}

When users use mouse to click the button, everything is fine. But there is a
problem when they use space bar on keyboard:
if you move focus (using TAB key) to SAVE button and then press space bar
two times very quickly, the save procedure successfully executes without
showing confirmation MessageBox. I guess, MessageBox does not appear on the
screen because second stroke of space bar closes it before it is drawn.
As a result, user does not confirmation that object is saved. Even worse, if
you press space bar 4 times, the object will be saved 2 times without
confirmation!

I'd like to make sure user always gets the confirmation, i.e. MessageBox
always shows and waits until user closes it explicitly, ignoring all pending
key strokes that might be in the buffer at the moment when SaveObject()
procedure ends.

If there are users to whom this is happening, I would classify it as a
problem those users have with using a computer rather than a problem
they are having with your application, and therefore outside the scope
of my concern. People who use the keyboard to activate button controls
either know how to do that, in which case there isn't a problem for your
to fix, or don't, in which case their problem is pervasive and they are
doomed unless they figure out what they are doing wrong. Having a single
application out there that has special code to save these people from
themselves in exactly one instance isn't really doing them a big favor.

 

[Alex K.]

Johnny,

thank you for your response. That solution was the first that came to my
mind. But it didn't work because:

On the form, there are a lot of other controls: textboxes, combo lists,
buttons, etc.
When I disable SAVE button, input focus jumps to other control, which can be
different depending on some conditions - somtimes, it can be another button
which in turn receives keyboard events ... Things become even worse and
messier

 

[Alex K.]

Peter,

thank you for your response. I tried your solution. Unfortunately, it did
not work. Yes, I can control the duration of my own modal dialog. Even
better, I can use only MouseClick event of OK button, forcing user to always
use mouse to aknowledge the confirmation, but ... If I press space bar 4
times very quickly, by the time my _first_ dialog appears on the screen,
object is already saved _twice_, as I can see in database, and in
console.debug lines. It looks like modal dialog stops the execution only
after it is drawn on the screen, while keyboard events are placed in a queue
that is separate from GUI and is moving faster.

Probably, I will ask users always use mouse when clicking on SAVE button,
and if they agree (hopefully) I'll ignore Click event and move all the SAVE
code to MouseClick event.

Thank you

[...]
I'd like to make sure user always gets the confirmation, i.e. MessageBox
always shows and waits until user closes it explicitly, ignoring all pending
key strokes that might be in the buffer at the moment when SaveObject()
procedure ends.

The user _does_ always get the confirmation. They just happen to
dismiss it before it's been around long enough for them to see it.

As for clearing the keyboard buffer, no….NET doesn't have anything for
that. But even if it did, it wouldn't help. There will _always_ be a
point in time during which the user can enter input that would dismiss
the MessageBox before the user's had a chance to see it.

A better solution would be for you to implement your own modal dialog
for the purpose. It's fairly trivial to design a regular Form sub-class
that will show the information the way you want.

Once you've done that, you can include a timer in the Form, override the
OnFormClosing() method, and if the timer hasn't expired yet, cancel the
close. That will ensure that any input to close the Form sub-class
before whatever minimum time you choose has passed will be ignored.

Pete
.

 

[Peter Duniho]

Peter,

thank you for your response. I tried your solution. Unfortunately, it did
not work

The suggestion I offered will work to correct the problem you originally
described.

Yes, I can control the duration of my own modal dialog. Even
better, I can use only MouseClick event of OK button, forcing user to always
use mouse to aknowledge the confirmation, but ... If I press space bar 4
times very quickly, by the time my _first_ dialog appears on the screen,
object is already saved _twice_, as I can see in database, and in
console.debug lines.

That's a completely different issue, which you would have to solve a
completely different way. Such as, not allowing new input to save an
object until you're done processing a previous input to save an object.

I agree with Harlan's point that you seem to be trying to protect stupid
users from themselves, which is a futile goal in most cases. But the
fact is that in this particular case, there are solutions available to
you that don't involve clearing the input buffer.

[...]
Probably, I will ask users always use mouse when clicking on SAVE button,
and if they agree (hopefully) I'll ignore Click event and move all the SAVE
code to MouseClick event.

If you are trying to help the user, making your program less convenient
to use is probably not the right approach.

Pete