Input Device Problems

[=?Utf-8?B?anAybXNmdA==?=]

I've got an application that takes input from a handheld scanner: Once the
incoming text meets the RegEx format and is the correct length, the command
is accepted.

The scanner that plugs in on the keyboard port.

The problem comes from the use of the default MessageBox whenever I need to
display information to the operator:

DialogResult dr =
MessageBox.Show("Do this?", Title,
MessageBoxButtons.YesNo,
MessageBoxIcon.Question,
DefaultButton.Button1);

Sometimes, these scanners send in more data (usually blank spaces) after a
MessageBox is displayed, and (as some of you may know) the space bar can be
used to select the default button.

I would like to flush the scanner's buffer, effectively flushing the
keyboard buffer? Are p/invoke calls needed for this, or is there something in
the Framework?

I'm running 2.0 Framework with Visual Studio 2005 - but I'll take tips and
how-to info from just about anything.

Thanks,
~Joe

[Peter Duniho]

On Thu, 30 Oct 2008 12:44:11 -0700, jp2msft
<jp*****@discussions.microsoft.comwrote:

[...]
Sometimes, these scanners send in more data (usually blank spaces) after
a
MessageBox is displayed, and (as some of you may know) the space bar can
be
used to select the default button.

I would like to flush the scanner's buffer, effectively flushing the
keyboard buffer? Are p/invoke calls needed for this, or is there
something in
the Framework?

How are you handling the input currently? Is there an existing form or
something that you're using to read the keyboard input?

I don't think that flushing the buffer is necessarily going to work,
depending on how the scanner itself behaves. But, if it _would_ work,
then it seems to me that you really should just not display the MessageBox
until the same code that reads the scanner input has itself consumed the
remainder of the data.

You may want to simply read until there's no data available, or read for
some specific amount of time (half a second or something like
that...enough to get all the data, but not so much that the user will feel
like there's some lag).

Note that if this approach wouldn't work, then flushing the buffer
wouldn't work either, because the only reason either won't work is the
same: data could come in after you think you're done reading it.

Another alternative is to create your own modal dialog rather than relying
on the MessageBox, and in that dialog handle keyboard input however you
like, ignoring a spacebar input if that's what you want to do.

Pete

[=?Utf-8?B?anAybXNmdA==?=]

Hi Pete,

Thanks for the fast response!

Yes: There is a form that is waiting on input. The problem is complicated by
the fact that both a scanner and the keyboard are allowed - just in case an
item is too dirty to be scanned, a scanner gets dropped/smashed, or any other
unforeseeable (sp?) mishap.

The keyboard requirement prevents implimenting a timer, and processing
starts once the RegEx expression is met.

Creating a custom modal form is a good idea. I did think of this myself, but
dismissed it, thinking that this was a more complicated solution than
learning how to use tools that were at my disposal.

Along that same line, now I am thinking about shifting the Focus to a
ReadOnly textbox as soon as the RegEx expression is met. This should allow
all of the remaining buffer characters to be consumed without anything in my
application trying to use them. It still sounds like a hack, though. :)

"Peter Duniho" wrote:

On Thu, 30 Oct 2008 12:44:11 -0700, jp2msft
How are you handling the input currently? Is there an existing form or
something that you're using to read the keyboard input?

I don't think that flushing the buffer is necessarily going to work,
depending on how the scanner itself behaves. But, if it _would_ work,
then it seems to me that you really should just not display the MessageBox
until the same code that reads the scanner input has itself consumed the
remainder of the data.

You may want to simply read until there's no data available, or read for
some specific amount of time (half a second or something like
that...enough to get all the data, but not so much that the user will feel
like there's some lag).

Note that if this approach wouldn't work, then flushing the buffer
wouldn't work either, because the only reason either won't work is the
same: data could come in after you think you're done reading it.

Another alternative is to create your own modal dialog rather than relying
on the MessageBox, and in that dialog handle keyboard input however you
like, ignoring a spacebar input if that's what you want to do.

Pete

[Peter Duniho]

On Thu, 30 Oct 2008 13:28:08 -0700, jp2msft
<jp*****@discussions.microsoft.comwrote:

Hi Pete,

Thanks for the fast response!

Yes: There is a form that is waiting on input. The problem is
complicated by
the fact that both a scanner and the keyboard are allowed - just in case
an
item is too dirty to be scanned, a scanner gets dropped/smashed, or any
other
unforeseeable (sp?) mishap.

The keyboard requirement prevents implimenting a timer, and processing
starts once the RegEx expression is met.

Why does the keyboard requirement prevent using a timer? All you'd be
trying to do is ensure you've consumed all of the input currently
available. Even if the user can type as fast as the scanner can send
input, it should be the same goal and thus same logic, and for mortal
human users, they are likely to simply enter the data you want them to and
then wait. A short timer won't even be noticeable to them.

As far as whether processing starts as soon as the RegEx expression is met
goes, well...you wrote this code, right? You have control over when
processing actually starts. Besides, as I understand it, processing
doesn't literally start as soon as the pattern is matched, because you
prompt the user for confirmation first. So all we're really talking about
here is a short delay before that confirmation dialog is presented.

Again, a half second delay (or whatever you decide is appropriate for the
purpose of consuming whatever data is left from the scanner) should be
perfectly fine.

Creating a custom modal form is a good idea. I did think of this myself,
but
dismissed it, thinking that this was a more complicated solution than
learning how to use tools that were at my disposal.

A modal form is practically the same in implementation as any other form.
If you've already coded a form that can take the input from the scanner,
then I think you already have the knowledge needed to do something similar
in a modal form.

Along that same line, now I am thinking about shifting the Focus to a
ReadOnly textbox as soon as the RegEx expression is met. This should
allow
all of the remaining buffer characters to be consumed without anything
in my
application trying to use them. It still sounds like a hack, though. :)

I don't understand the description. The problem, as I understand it, is
that the remaining input is processed by the modal MessageBox you
display. Unless you delay presentation of that MessageBox long enough for
the read-only TextBox to consume the remaining input, shifting the focus
won't help.

If you _do_ delay presentation of the MessageBox, then that's basically
just the timer-based solution I proposed earlier. Right?

Pete

[=?Utf-8?B?anAybXNmdA==?=]

Sometimes my head can be hard, and it is difficult to get a new idea or two
in there. But, this time I did it! ;)

I've got a timer checking the input. As it turned out, there was already a
timer on the form ticking every 200 ms, so I just added a text input checker
to that routine.

Thanks for being patient with an old, hard headed donkey!

"Peter Duniho" wrote:

Why does the keyboard requirement prevent using a timer? All you'd be
trying to do is ensure you've consumed all of the input currently
available. Even if the user can type as fast as the scanner can send
input, it should be the same goal and thus same logic, and for mortal
human users, they are likely to simply enter the data you want them to and
then wait. A short timer won't even be noticeable to them.

As far as whether processing starts as soon as the RegEx expression is met
goes, well...you wrote this code, right? You have control over when
processing actually starts. Besides, as I understand it, processing
doesn't literally start as soon as the pattern is matched, because you
prompt the user for confirmation first. So all we're really talking about
here is a short delay before that confirmation dialog is presented.

Again, a half second delay (or whatever you decide is appropriate for the
purpose of consuming whatever data is left from the scanner) should be
perfectly fine.