KeyPress problem in VB.NET - any ideas welcome

[Niksa Baldun]

Hi,

I am trying to capture data from magnetic stripe reader which is connected
via keyboard interface (therefore indistinguishable from normal keyboard
input). Basically, I am doing the following (in the Form.Keypress event
handler):

strCardData &= e.KeyChar
e.Handled = True

As you can see, I capture the input from the reader, and then prevent the
active control from receiving keyboard data. However, some characters get
lost, that is KeyPress event is not fired for all "keystrokes". It appears
to be random, but every time at least one character is lost. I figured that
one of the controls on the form is causing this, but after I removed ALL the
controls the problem still persists.

However, if I display another form modally, the same procedure works like a
charm there.

Like I said, any ideas are welcome, since I cannot even imagine what could
prevent the triggering of KeyPress event. Alternatively, perhaps someone
could suggest a different method of capturing keyboard data.

Thanks,

Niksa

[_Andy_]

On Sun, 30 Nov 2003 15:59:49 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

Hi,

I am trying to capture data from magnetic stripe reader which is connected
via keyboard interface (therefore indistinguishable from normal keyboard
input). Basically, I am doing the following (in the Form.Keypress event
handler):

strCardData &= e.KeyChar
e.Handled = True

As you can see, I capture the input from the reader, and then prevent the
active control from receiving keyboard data. However, some characters get
lost, that is KeyPress event is not fired for all "keystrokes". It appears
to be random, but every time at least one character is lost. I figured that
one of the controls on the form is causing this, but after I removed ALL the
controls the problem still persists.

However, if I display another form modally, the same procedure works like a
charm there.

Like I said, any ideas are welcome, since I cannot even imagine what could
prevent the triggering of KeyPress event. Alternatively, perhaps someone
could suggest a different method of capturing keyboard data.

Thanks,

Niksa

I'm not sure if this is related to your problem, but some keys affect
focus - so the current control/form will change (and therefore the
event will be sent elsewhere). You can change this behaviour by
changing the control type to specify you want to hear all key presses.

Here's some C# cut out of one of my programs, you will immediately see
how to change it to VB.NET. I wrote this so I could handle cursor key
events on a user control, but it'll work for anything:

protected override void WndProc(ref System.Windows.Forms.Message m)
{
if( m.Msg == 0x87 )
{
m.Result = (IntPtr) 4; // DLGC_WANTALLKEYS
}
else
{
base.WndProc( ref m );
}
}

Probably not the answer to your problem, but it may prove useful.

Rgds,

[Niksa Baldun]

No, didn't help.

I considered that focus my be shifted somehow, but it is not caused by input
from the reader - it is just regular alphanumeric data.

Just to make sure, please see if I converted your proc to VB correctly:

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
If m.Msg = &H87 Then
m.Result = New IntPtr(4) 'DLGC_WANTALLKEYS
Else
MyBase.WndProc(m)
End If
End Sub

Thanks

"_Andy_" <wi******@nospamthanks.gov> wrote in message
news:pa********************************@4ax.com...

On Sun, 30 Nov 2003 15:59:49 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

Hi,

I am trying to capture data from magnetic stripe reader which is connectedvia keyboard interface (therefore indistinguishable from normal keyboard
input). Basically, I am doing the following (in the Form.Keypress event
handler):

strCardData &= e.KeyChar
e.Handled = True

As you can see, I capture the input from the reader, and then prevent the
active control from receiving keyboard data. However, some characters get
lost, that is KeyPress event is not fired for all "keystrokes". It appearsto be random, but every time at least one character is lost. I figured thatone of the controls on the form is causing this, but after I removed ALL thecontrols the problem still persists.

However, if I display another form modally, the same procedure works like acharm there.

Like I said, any ideas are welcome, since I cannot even imagine what couldprevent the triggering of KeyPress event. Alternatively, perhaps someone
could suggest a different method of capturing keyboard data.

Thanks,

Niksa

I'm not sure if this is related to your problem, but some keys affect
focus - so the current control/form will change (and therefore the
event will be sent elsewhere). You can change this behaviour by
changing the control type to specify you want to hear all key presses.

Here's some C# cut out of one of my programs, you will immediately see
how to change it to VB.NET. I wrote this so I could handle cursor key
events on a user control, but it'll work for anything:

protected override void WndProc(ref System.Windows.Forms.Message m)
{
if( m.Msg == 0x87 )
{
m.Result = (IntPtr) 4; // DLGC_WANTALLKEYS
}
else
{
base.WndProc( ref m );
}
}

Probably not the answer to your problem, but it may prove useful.

Rgds,

[_Andy_]

On Mon, 1 Dec 2003 09:03:09 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

No, didn't help.

I considered that focus my be shifted somehow, but it is not caused by input
from the reader - it is just regular alphanumeric data.

Just to make sure, please see if I converted your proc to VB correctly:

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
If m.Msg = &H87 Then
m.Result = New IntPtr(4) 'DLGC_WANTALLKEYS
Else
MyBase.WndProc(m)
End If
End Sub

Thanks

That's the right conversion - it caters for when the framework filters
out certain key presses.

Do you get the right sequence in KeyDown/KeyUp? If you're certain the
barcode data is alphanumeric (and normally has a CRLF at the end),
then I'm at a bit of a loss. Perhaps the driver for the reader is
opening a window somewhere that might affect focus? Spyxx might be
useful...

As a quick test. Put a textbox onto the form with a default button
("OK"). Set focus to the textbox and then scan the barcode. Does that
work?

Rgds,

[Niksa Baldun]

Hi,

I have tried putting the textbox on the form, but the result is the same -
some characters don't make it to the textbox. BUT if I comment out the
KeyPress event handler, everything works fine. As long as the event handler
exists, even if there is no code in it, and even if KeyPreview is set to
False, the error persists. But it is also interesting that, in a modal form
with only a command button on it, the error never appears.

Therefore I can only assume this is some kind of a bug in .NET framework,
unfortunately the one I can't find the workaround for. I will try and see if
there are any patches available - perhaps the issue has been resolved.

Anyway, thanks for taking the interest in my problem.
Niksa
"_Andy_" <wi******@nospamthanks.gov> wrote in message
news:90********************************@4ax.com...

On Mon, 1 Dec 2003 09:03:09 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

No, didn't help.

I considered that focus my be shifted somehow, but it is not caused by inputfrom the reader - it is just regular alphanumeric data.

Just to make sure, please see if I converted your proc to VB correctly:

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
If m.Msg = &H87 Then
m.Result = New IntPtr(4) 'DLGC_WANTALLKEYS
Else
MyBase.WndProc(m)
End If
End Sub

Thanks

That's the right conversion - it caters for when the framework filters
out certain key presses.

Do you get the right sequence in KeyDown/KeyUp? If you're certain the
barcode data is alphanumeric (and normally has a CRLF at the end),
then I'm at a bit of a loss. Perhaps the driver for the reader is
opening a window somewhere that might affect focus? Spyxx might be
useful...

As a quick test. Put a textbox onto the form with a default button
("OK"). Set focus to the textbox and then scan the barcode. Does that
work?

Rgds,

[Fredrik Melin]

Yes, Keypress and all keyinput events are buggy, in Framework 1.1 at least.

We have a larger app where the enter key stops working sooner or later (it
happens app wide, only restart will fix it..), instead the last button used
get's clicked. (in my case i've teached the user to use cltr-enter instead
that seems to work all the time..)
But barcode readers work flawless in my application, both in modal and
modaless screens.
I let them scan to a text field though, with tab as last char, and then I
trap the input on normal validate event.

- Fredrik

"Niksa Baldun" <di***********@du.htnet.hr> wrote in message
news:u4*************@tk2msftngp13.phx.gbl...

Hi,

I have tried putting the textbox on the form, but the result is the same -
some characters don't make it to the textbox. BUT if I comment out the
KeyPress event handler, everything works fine. As long as the event handler exists, even if there is no code in it, and even if KeyPreview is set to
False, the error persists. But it is also interesting that, in a modal form with only a command button on it, the error never appears.

Therefore I can only assume this is some kind of a bug in .NET framework,
unfortunately the one I can't find the workaround for. I will try and see if there are any patches available - perhaps the issue has been resolved.

Anyway, thanks for taking the interest in my problem.
Niksa
"_Andy_" <wi******@nospamthanks.gov> wrote in message
news:90********************************@4ax.com...

On Mon, 1 Dec 2003 09:03:09 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

No, didn't help.

I considered that focus my be shifted somehow, but it is not caused by inputfrom the reader - it is just regular alphanumeric data.

Just to make sure, please see if I converted your proc to VB correctly:

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)If m.Msg = &H87 Then
m.Result = New IntPtr(4) 'DLGC_WANTALLKEYS
Else
MyBase.WndProc(m)
End If
End Sub

Thanks

That's the right conversion - it caters for when the framework filters
out certain key presses.

Do you get the right sequence in KeyDown/KeyUp? If you're certain the
barcode data is alphanumeric (and normally has a CRLF at the end),
then I'm at a bit of a loss. Perhaps the driver for the reader is
opening a window somewhere that might affect focus? Spyxx might be
useful...

As a quick test. Put a textbox onto the form with a default button
("OK"). Set focus to the textbox and then scan the barcode. Does that
work?

Rgds,

[Niksa Baldun]

I don't have a barcode reader, but magnetic stripe reader (although there
should be no difference in output). I have tried using the text box too, but
the result is the same - characters get lost.

You have kind of discouraged me because I am using Framework 1.0 and hoped
that upgrading to 1.1 may solve my problem.

Nevertheless, thanks for the input.
Niksa

"Fredrik Melin" <me*@n.o.spam.dacsa.net.remove.as.needed> wrote in message
news:uM**************@tk2msftngp13.phx.gbl...

Yes, Keypress and all keyinput events are buggy, in Framework 1.1 at least.
We have a larger app where the enter key stops working sooner or later (it
happens app wide, only restart will fix it..), instead the last button used get's clicked. (in my case i've teached the user to use cltr-enter instead
that seems to work all the time..)
But barcode readers work flawless in my application, both in modal and
modaless screens.
I let them scan to a text field though, with tab as last char, and then I
trap the input on normal validate event.

- Fredrik

"Niksa Baldun" <di***********@du.htnet.hr> wrote in message
news:u4*************@tk2msftngp13.phx.gbl...

Hi,

I have tried putting the textbox on the form, but the result is the same -

some characters don't make it to the textbox. BUT if I comment out the
KeyPress event handler, everything works fine. As long as the event handler

exists, even if there is no code in it, and even if KeyPreview is set to
False, the error persists. But it is also interesting that, in a modal

form

with only a command button on it, the error never appears.

Therefore I can only assume this is some kind of a bug in .NET framework, unfortunately the one I can't find the workaround for. I will try and see if

there are any patches available - perhaps the issue has been resolved.

Anyway, thanks for taking the interest in my problem.
Niksa
"_Andy_" <wi******@nospamthanks.gov> wrote in message
news:90********************************@4ax.com...

On Mon, 1 Dec 2003 09:03:09 +0100, "Niksa Baldun"
<di***********@du.htnet.hr> wrote:

>No, didn't help.
>
>I considered that focus my be shifted somehow, but it is not caused by input

>from the reader - it is just regular alphanumeric data.
>
>Just to make sure, please see if I converted your proc to VB

correctly: >
>Protected Overrides Sub WndProc(ByRef m As

System.Windows.Forms.Message) >If m.Msg = &H87 Then
> m.Result = New IntPtr(4) 'DLGC_WANTALLKEYS
>Else
> MyBase.WndProc(m)
>End If
>End Sub
>
>Thanks

That's the right conversion - it caters for when the framework filters
out certain key presses.

Do you get the right sequence in KeyDown/KeyUp? If you're certain the
barcode data is alphanumeric (and normally has a CRLF at the end),
then I'm at a bit of a loss. Perhaps the driver for the reader is
opening a window somewhere that might affect focus? Spyxx might be
useful...

As a quick test. Put a textbox onto the form with a default button
("OK"). Set focus to the textbox and then scan the barcode. Does that
work?

Rgds,