Trying to "display" control characters in a text box

[Ron L]

I have a barcode scanner which uses a "keyboard wedge" program so that the
data it scans comes through as if it was typed on a keyboard. I am trying
to have the data in the barcode be displayed in a text box. I know that
there are certain control characters embedded in the data that I want to
display substitutions for in the text box, for instance I want to replace
ASCII character 04 with the string "<EOT>". I have tried doing a simple
replace in the TextChanged event, but it appears that the Textbox Control
strips out the control characters as they come in. I also tried catching
the "keystrokes" using the KeyUp event, but that seems to have done
something (and I can't figure out what) with some of the control characters
and added other characters that are not in the data. Does anyone have any
suggestions as to how I can accomplish this? I know what the data encoded
in the barcode is, and I can verify that the scanner is reading it
properly - I just can't get it into a VB.Net text box properly.

TIA
Ron L

 

[Guest]

Try creating a simple Console Application and read in the keyboard buffer,
this should make it easier to 'Replace' non printable characters...

 

[Stoitcho Goutsev \(100\)]

Ron,

How the barcode scanner enters this ASCII (04)? Is it actully simulates
pressing Ctrl+D? If it does it is no surprise that the TextBox strips them
out - for the TextBox Ctrl+D is not defined shortcut so it just skips it
(probably it produces some beeping sound depending on the sound scheme). The
same way the TextBox will perfome copy operation if your barcode scanner is
trying to send ASCII(03) in this way.

 

[R. MacDonald]

Hello, Ron,

Is it possible that you can move the scanned input to a String variable
first. If so then you can just replace the control characters in the
string before you move it to the TextBox. Something like:

TextBox1.text = ReplaceCCs(strInput)

where ReplaceCCs is a function, in VB something like:

Private Function ReplaceCCs(ByVal Input As String) As String

' Fill in the "TBC"s with appropriate replacement strings:
Dim straSubs() As String = {"<Nul>", "<TBC>", "<TBC>", "<TBC>", _
"<TBC>", "<TBC>", "<TBC>", "<TBC>", _
"<TBC>", "<Tab>", "<LF>", "<VT>", _
"<FF>", "<CR>", "<TBC>", "<TBC>", _
"<TBC>", "<TBC>", "<TBC>", "<TBC>", _
"<TBC>", "<TBC>", "<TBC>", "<TBC>", _
"<TBC>", "<TBC>", "<TBC>", "<TBC>", _
"<TBC>", "<TBC>", "<TBC>", "<TBC>"}
Dim strOut As String = Input
For intChar As Integer = 0 To 31
strOut = strOut.Replace(Chr(intChar), straSubs(intChar))
Next intChar

strOut = strOut.Replace(Chr(127), "<Del>")

Return strOut

End Function

I've been a bit lazy, and not filled in all the appropriate substitution
codes -- just a few I could easily remember.

Cheers,
Randy

 

[Ron L]

Randy

Thanks for the response. My problem is that the scanner acts like a
keyboard, so I'm not sure how to get the original informaion into a string
in the first place. I have tried catching the key up event, but I haven't
figured out what to place in the string to get the control characters into
the string. I have printed out the key values, and can't find a correlation
between the key value or key code and the control character I am expecting
to see.

Ron L

 

[R. MacDonald]

Hello, Ron,

I've never worked with a scanner, so please excuse my ignorance. What
kind of control is it that receives the input? (I had assumed it would
be something akin to a TextBox and you could just use the Text property
after completion of the input.)

But when you say that you're catching the key-up event, perhaps the
processing required is more sophisticated than I realized.

Can you provide any additional information, or perhaps an example of the
code that you are trying to make work?

Cheers,
Randy

 

[Ron L]

Randy

I am using a text box control, but apparently there is logic in that control
that strips out most of the control characters (ASCII values < 32) before
entering them into the Text property. I had hoped that by catching the
Key-up event I could somehow "bypass" the code that removes the control
characters.

As far as the scanner is concerned, it is simply acting as if it is a
keyboard and is sending on the characters that were "typed".

Thanks,

Ron L

 

[R. MacDonald]

Hello, Ron,

I'm not aware of any logic that strips out control characters from a
TextBox. For example, when I type into a multiline textBox using a
keyboard I can easily insert new line characters (<CR><LF>) by typing
<CNTL><Enter>, or other control characters by using Copy/Paste. These
are returned in the Text property.

Also, almost all keystrokes (including the Control keys) are available
via the Key-up events. (As I recall there are a few "navigation" keys
that do not normally appear there, but I think that even these can be
persuaded to appear with a little extra work.)

I wonder if there is something between the scanner driver and the
TextBox that is swallowing the characters you are expecting to see. Do
you have KeyPreview enabled for the Form that contains the TextBox? Or
is there possibly something more sophisticated such as an override of
WndProc interfering?

Anyway, I'm rather doubtful that the problem is with the TextBox.

Cheers,
Randy

 

[Ron L]

Randy

Sorry, I should have been more specific. The text box removes *some* of the
control characters. My string has the RS (ASCII 30), GS (ASCII 29), and EOT
(ASCII 4) embedded in it. These are commonly represented as ctl-^, ctl-],
and ctl-D, respectively. If I open a command prompt and scan the label I
see all the expected control characters on the entered line, but in the text
box the GS and EOT have been stripped out! Given that, I am reasonably that
either the TextBox or some portion of the windows key event handling is
removing the GS and EOT characters from my input string.

Arrggghhhh!


Ron L

 

[R. MacDonald]

Hello, Ron,

Perhaps these keys are being swallowed by some preprocessing on the
form. Have a look at the help for the "IsInputKey" (and possibly the
"IsInputChar") function. Perhaps they will help you out. I have
previously used the former in order to "capture" some of the navigation
keys. Here is an example of IsInputKey:

Protected Overrides _
Function IsInputKey(ByVal keyData As Keys) As Boolean
' Inhibit pre-processing for selected "special" keys
' that are handled directly by the control.
Select Case keyData
Case Keys.Down, Keys.Left, Keys.Right, Keys.Up
Return (Me.UserMode = aenmUserMode.Design)
Case Else
Return False
End Select

End Function

Cheers,
Randy

Randy

Sorry, I should have been more specific. The text box removes *some* of the
control characters. My string has the RS (ASCII 30), GS (ASCII 29), and EOT
(ASCII 4) embedded in it. These are commonly represented as ctl-^, ctl-],
and ctl-D, respectively. If I open a command prompt and scan the label I
see all the expected control characters on the entered line, but in the text
box the GS and EOT have been stripped out! Given that, I am reasonably that
either the TextBox or some portion of the windows key event handling is
removing the GS and EOT characters from my input string.

Arrggghhhh!


Ron L

Hello, Ron,

I'm not aware of any logic that strips out control characters from a
TextBox. For example, when I type into a multiline textBox using a
keyboard I can easily insert new line characters (<CR><LF>) by typing
<CNTL><Enter>, or other control characters by using Copy/Paste. These are
returned in the Text property.

Also, almost all keystrokes (including the Control keys) are available via
the Key-up events. (As I recall there are a few "navigation" keys that do
not normally appear there, but I think that even these can be persuaded to
appear with a little extra work.)

I wonder if there is something between the scanner driver and the TextBox
that is swallowing the characters you are expecting to see. Do you have
KeyPreview enabled for the Form that contains the TextBox? Or is there
possibly something more sophisticated such as an override of WndProc
interfering?

Anyway, I'm rather doubtful that the problem is with the TextBox.

Cheers,
Randy


Ron L wrote:

 

[Ron L]

Randy

Thanks, that definitely was a step in the right direction. I put in both
the IsInputKey and IsInputChar routines (included below) and I now get the
RS character in the final output. I still don't get the GS and EOT
characters, though, even though they are handled in the IsInputChar routine
(I see the debug printouts). I suspect that this is due to a problem with
how I am handling them in the IsInputKey routine. Do you have any other
suggestions?

Thanks again,
Ron L


'********************* ControlCharactersTextBox Class
********************************
Imports System.Windows.Forms

Public Class CtlCharTextBox
Inherits System.Windows.Forms.TextBox

Protected Overrides Function IsInputKey(ByVal keyData As
System.Windows.Forms.Keys) As Boolean
If (keyData And Keys.Control) And (keyData And Keys.D) Then
Debug.WriteLine("IsInputKey: <EOT>")
Return True
ElseIf (keyData And Keys.Control) And (keyData And
Keys.OemCloseBrackets) Then
Debug.WriteLine("IsInputKey: <GS>")
Return True
ElseIf (keyData And Keys.Control) And (keyData And Keys.D6) Then
Debug.WriteLine("IsInputKey: <RS>")
Return True
Else
Return MyBase.IsInputKey(keyData)
End If
End Function

Protected Overrides Function IsInputChar(ByVal charCode As Char) As
Boolean
'Return MyBase.IsInputChar(charCode)
Select Case Asc(charCode)
Case 4 ' EOT character
'Debug.Write(Asc(charCode) & ", " & "<EOT> ")
Return True
Case 29 ' GS character
'Debug.Write(Asc(charCode) & ", " & "<GS> ")
Return True
Case 30 ' RS character
'Debug.Write(Asc(charCode) & ", " & "<RS> ")
Return True
Case Else
'Debug.Write(Asc(charCode) & ", " & charCode & " ")
Return MyBase.IsInputChar(charCode)
End Select
End Function
End Class

Hello, Ron,

Perhaps these keys are being swallowed by some preprocessing on the form.
Have a look at the help for the "IsInputKey" (and possibly the
"IsInputChar") function. Perhaps they will help you out. I have
previously used the former in order to "capture" some of the navigation
keys. Here is an example of IsInputKey:

Protected Overrides _
Function IsInputKey(ByVal keyData As Keys) As Boolean
' Inhibit pre-processing for selected "special" keys
' that are handled directly by the control.
Select Case keyData
Case Keys.Down, Keys.Left, Keys.Right, Keys.Up
Return (Me.UserMode = aenmUserMode.Design)
Case Else
Return False
End Select

End Function

Cheers,
Randy

Randy

Sorry, I should have been more specific. The text box removes *some* of
the control characters. My string has the RS (ASCII 30), GS (ASCII 29),
and EOT (ASCII 4) embedded in it. These are commonly represented as
ctl-^, ctl-], and ctl-D, respectively. If I open a command prompt and
scan the label I see all the expected control characters on the entered
line, but in the text box the GS and EOT have been stripped out! Given
that, I am reasonably that either the TextBox or some portion of the
windows key event handling is removing the GS and EOT characters from my
input string.

Arrggghhhh!


Ron L

Hello, Ron,

I'm not aware of any logic that strips out control characters from a
TextBox. For example, when I type into a multiline textBox using a
keyboard I can easily insert new line characters (<CR><LF>) by typing
<CNTL><Enter>, or other control characters by using Copy/Paste. These
are returned in the Text property.

Also, almost all keystrokes (including the Control keys) are available
via the Key-up events. (As I recall there are a few "navigation" keys
that do not normally appear there, but I think that even these can be
persuaded to appear with a little extra work.)

I wonder if there is something between the scanner driver and the TextBox
that is swallowing the characters you are expecting to see. Do you have
KeyPreview enabled for the Form that contains the TextBox? Or is there
possibly something more sophisticated such as an override of WndProc
interfering?

Anyway, I'm rather doubtful that the problem is with the TextBox.

Cheers,
Randy


Ron L wrote:


Randy

I am using a text box control, but apparently there is logic in that
control that strips out most of the control characters (ASCII values <
32) before entering them into the Text property. I had hoped that by
catching the Key-up event I could somehow "bypass" the code that removes
the control characters.

As far as the scanner is concerned, it is simply acting as if it is a
keyboard and is sending on the characters that were "typed".

Thanks,

Ron L



Hello, Ron,

I've never worked with a scanner, so please excuse my ignorance. What
kind of control is it that receives the input? (I had assumed it would
be something akin to a TextBox and you could just use the Text property
after completion of the input.)

But when you say that you're catching the key-up event, perhaps the
processing required is more sophisticated than I realized.

Can you provide any additional information, or perhaps an example of
the code that you are trying to make work?

Cheers,
Randy


Ron L wrote:


Randy

Thanks for the response. My problem is that the scanner acts like a
keyboard, so I'm not sure how to get the original informaion into a
string in the first place. I have tried catching the key up event,
but I haven't figured out what to place in the string to get the
control characters into the string. I have printed out the key
values, and can't find a correlation between the key value or key code
and the control character I am expecting to see.

Ron L

 

[R. MacDonald]

Hello, Ron,

I'm at a bit of a loss here. But I'm thinking that the TextBox control
might not be your best solution. I'm afraid that I'm out of my depth
here, and so can't give you much good advice, but here are some
"under-processed" thoughts:

Perhaps you can simply capture the characters that you need in the
IsInputKey or IsCharKey routine and build the "text" string yourself.
You probably don't even need the text box then, just a control of your
own, inherited from Control.

Maybe you'll have to spawn a batch file to capture the input into a text
file and then read that.

Or perhaps you can use something like WndProc to capture the keys at
some lower level.

Have you consulted with the vendor/manufacturer of the barcode scanner
to see if they have any suggestions?

Good luck,
Randy

Randy

Thanks, that definitely was a step in the right direction. I put in both
the IsInputKey and IsInputChar routines (included below) and I now get the
RS character in the final output. I still don't get the GS and EOT
characters, though, even though they are handled in the IsInputChar routine
(I see the debug printouts). I suspect that this is due to a problem with
how I am handling them in the IsInputKey routine. Do you have any other
suggestions?

Thanks again,
Ron L


'********************* ControlCharactersTextBox Class
********************************
Imports System.Windows.Forms

Public Class CtlCharTextBox
Inherits System.Windows.Forms.TextBox

Protected Overrides Function IsInputKey(ByVal keyData As
System.Windows.Forms.Keys) As Boolean
If (keyData And Keys.Control) And (keyData And Keys.D) Then
Debug.WriteLine("IsInputKey: <EOT>")
Return True
ElseIf (keyData And Keys.Control) And (keyData And
Keys.OemCloseBrackets) Then
Debug.WriteLine("IsInputKey: <GS>")
Return True
ElseIf (keyData And Keys.Control) And (keyData And Keys.D6) Then
Debug.WriteLine("IsInputKey: <RS>")
Return True
Else
Return MyBase.IsInputKey(keyData)
End If
End Function

Protected Overrides Function IsInputChar(ByVal charCode As Char) As
Boolean
'Return MyBase.IsInputChar(charCode)
Select Case Asc(charCode)
Case 4 ' EOT character
'Debug.Write(Asc(charCode) & ", " & "<EOT> ")
Return True
Case 29 ' GS character
'Debug.Write(Asc(charCode) & ", " & "<GS> ")
Return True
Case 30 ' RS character
'Debug.Write(Asc(charCode) & ", " & "<RS> ")
Return True
Case Else
'Debug.Write(Asc(charCode) & ", " & charCode & " ")
Return MyBase.IsInputChar(charCode)
End Select
End Function
End Class

Hello, Ron,

Perhaps these keys are being swallowed by some preprocessing on the form.
Have a look at the help for the "IsInputKey" (and possibly the
"IsInputChar") function. Perhaps they will help you out. I have
previously used the former in order to "capture" some of the navigation
keys. Here is an example of IsInputKey:

Protected Overrides _
Function IsInputKey(ByVal keyData As Keys) As Boolean
' Inhibit pre-processing for selected "special" keys
' that are handled directly by the control.
Select Case keyData
Case Keys.Down, Keys.Left, Keys.Right, Keys.Up
Return (Me.UserMode = aenmUserMode.Design)
Case Else
Return False
End Select

End Function

Cheers,
Randy


Ron L wrote:

Randy

Sorry, I should have been more specific. The text box removes *some* of
the control characters. My string has the RS (ASCII 30), GS (ASCII 29),
and EOT (ASCII 4) embedded in it. These are commonly represented as
ctl-^, ctl-], and ctl-D, respectively. If I open a command prompt and
scan the label I see all the expected control characters on the entered
line, but in the text box the GS and EOT have been stripped out! Given
that, I am reasonably that either the TextBox or some portion of the
windows key event handling is removing the GS and EOT characters from my
input string.

Arrggghhhh!


Ron L




Hello, Ron,

I'm not aware of any logic that strips out control characters from a
TextBox. For example, when I type into a multiline textBox using a
keyboard I can easily insert new line characters (<CR><LF>) by typing
<CNTL><Enter>, or other control characters by using Copy/Paste. These
are returned in the Text property.

Also, almost all keystrokes (including the Control keys) are available
via the Key-up events. (As I recall there are a few "navigation" keys
that do not normally appear there, but I think that even these can be
persuaded to appear with a little extra work.)

I wonder if there is something between the scanner driver and the TextBox
that is swallowing the characters you are expecting to see. Do you have
KeyPreview enabled for the Form that contains the TextBox? Or is there
possibly something more sophisticated such as an override of WndProc
interfering?

Anyway, I'm rather doubtful that the problem is with the TextBox.

Cheers,
Randy


Ron L wrote:



Randy

I am using a text box control, but apparently there is logic in that
control that strips out most of the control characters (ASCII values <
32) before entering them into the Text property. I had hoped that by
catching the Key-up event I could somehow "bypass" the code that removes
the control characters.

As far as the scanner is concerned, it is simply acting as if it is a
keyboard and is sending on the characters that were "typed".

Thanks,

Ron L




Hello, Ron,

I've never worked with a scanner, so please excuse my ignorance. What
kind of control is it that receives the input? (I had assumed it would
be something akin to a TextBox and you could just use the Text property
after completion of the input.)

But when you say that you're catching the key-up event, perhaps the
processing required is more sophisticated than I realized.

Can you provide any additional information, or perhaps an example of
the code that you are trying to make work?

Cheers,
Randy


Ron L wrote:



Randy

Thanks for the response. My problem is that the scanner acts like a
keyboard, so I'm not sure how to get the original informaion into a
string in the first place. I have tried catching the key up event,
but I haven't figured out what to place in the string to get the
control characters into the string. I have printed out the key
values, and can't find a correlation between the key value or key code
and the control character I am expecting to see.

Ron L