Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Question on how best to parse text 2

Status
Not open for further replies.

robojeff

Technical User
Dec 5, 2008
220
US
I have a bar code which contains a "part number", a "from location", a "quantity", a "To location", and a "lot code" field and all of these fields are seperated by a tab.

A typical bar code might decode as follows:

N18-128200 WH 3 LOC04 1d2423
(part) (from) (qty) (to) lot)

Because these fields can be of different lengths, how
can I parse each field from an individual text box on my
form into certain controls on my form with extra space compression?

I envision having the user scan the bar code into one text box field on the form and then have this data populate certain controls on my form with the data derived from the bar code...

I would like to store the "part number" into Me.Part,
the from data into Me.from, the quantity into Me.qty, the
to data into Me.to, and the lot info into Me.lotsn

Is there an efficient way of doing this?


Thanks in advance...
 
ccv doesn't seem to like posting helpful responses to robojeff's posts (thread702-1574471)...

Andy
---------------------------------
[green]' Signature removed for testing purposes.[/green]

 
Not sure what spurred those inappropriate comments on from ccv, but it can't be all that important and definitely not worth wasting any energy on that at all...

But I did want to say that you guys are very helpful and I do appreciate that...
 
I didn't realise that your scanner appears to be one that acts like a keyboard. I thought it would have been serial.

You shouldn't have to change much or load special drivers

If so you can intercept the output (in vb6 and maybe vba ) with the keydown and keypress subs of the control that has the focus.

Each time a character is received it will fire this sub so you can accumulate the characters in a string
MyString=MyString & chr(Keycode)

You could even detect when it received a tab and put it in a different indexed LABEL box Eg


the character following go in a new box

Make sure you set Index = 0 and MyString = "" when you have finished handling the read (probably a If Keycode=vbCr means a Return Character or when 4 details have been received for an item) otherwise the string keeps getting bigger with every read

Following prints separate data in separate indexed labels with the same name lblDetails

Dim MyString as string
Dim MyIndex as integer

Sub Text1_KeyDown(KeyCode As Integer, Shift As Integer)
If Keycode=vbTab then Index=Index + 1:exit sub
If Keycode=vbCr of MyIndex > 3 then Mystring="":MyIndex=0
lblDetails(Index).caption=chr(keycode)
end sub

Also to get a string from your original routine just say
MyString=Text1.text
 
Most older POS systems are set up and run as keyboard emulation, regardless of the physical interface; serial, usb or PS2 port. The new standard and better practice is OPOS ocx's. While Yes, "You shouldn't have to change much or load special drivers" will work just fine. And maybe it is easiest for this situation, because it is being done through Access. But the advantages of OPOS ocx's which are event driven instead of "waiting" for text to change is significant. In my situation, I have multiple forms where either MSR or bar code data can be accepted. It is much simplier to retrieve and process this data though events as opposed to having to continually set focus on a text box or whatever object to change. Thats the reasoning behind my suggestion and why I use OPOS ocx's. With keyboard emulation, focus must still be set to the object designed to read the data after every other object has gained focus or keyboard emulation would just change the text on the object that currently has focus. The other option would require the user would have to do an extra step to say click a button such as process card, process bar code or accually see the text box, click on it then swipe/scan prior to physically swiping/scanning. One big reason the object to accept a MSR swipe should not be visible to the user is then they would be able to see the track data of a credit card. I know we aren't taking MSR's but they go hand in hand with bar code scanners in the POS industry, thus probably why the standardized logic is what it is.

Tom
 


YIKES!!!

Because I was having problems getting the ocx drivers to work with the bar code scanner (as it is a wedge reader type), I decided to just grab what was dumped in a text box on the form and parse the fields and split the data up for each control.

This was all well and good until a turn of events happened...

I tried this database in the area where it will be used only to find out that their bar code scanner does insert the tabs where mine did not. I know that this is most likely programmable but they need these to work in this fashion for other applications that they have.

I have tried the suggestions that everyone gave in this thread but the stream of data with the tabs over writes my code if I attempt to set a break point and I am not sure how to deal with this...

Even without breakpoints, an error is found and because there is actually an additional 8 or 9 fields on thie bar code seperated by tabs, that the error dialog box gets overwritten and I can't see what the error is or what is going on...

 
Getting back to your original request -

Your problem is you have to really know what separates the details and if there is a character at the end of the data to tell you the read is finished.

If the separating is Tab (Chr(9) then the following will work but you have to work out a way of knowing that all elements have been received usually indicated By Carriage Return chr(13) or Line Feed Chr(10).

To find out the value of the last character use something like
Debug.print Asc(Right(TextInput.Text),1))
on your received data

This will print the value of any character in the data
Debug.print Asc(Mid(TextInput.Text),CharacterPosition,1))

If there is no end character you could maybe count the number of tabs in the string in a Sub TextInput_Change


Try this to show you how to separate the received data:-
This puts the 5 elements of your original data separated by Tabs into 5 separate boxes
Create 1 TextInput box invisible for data entry
Set Multiline in the text box properties to True
Create 5 Text1 visible INDEXED boxes for details. Clear initial text in their properties.
(Copy the first one and past 4 copies back onto the form will automatically create the sequential indexes)

Code:
Private Sub Form_Load()
'Assumes vbTab delimits and vbCrLf ends each data
'Following line creates dummy data for testing
TextInput.Text = "N18-128200" & vbTab & "WH" & vbTab & "3" & vbTab & "LOC04" & vbTab & "1d2423" & vbCrLf
If Asc(Right(TextInput.Text, 1)) = 10 Then DataCollected
End Sub

Private Sub DataCollected()
Dim X As String, MyString As String, Index As Integer
MyString = TextInput.Text 'puts data into a string
For a = 1 To Len(MyString)
    X = Mid(MyString, a, 1) 'examines each character of the string
    If X = vbTab Then 'found a tab in the data
        Index = Index + 1 'step to next box
    Else
        If Index < 5 Then Text1(Index).Text = Text1(Index).Text & X 'put relevant data in the next box
    End If
Next
End Sub

Your final code would probably use the Sub TextInput_Change where I have used Sub Form_Load in the above example
 
>I was having problems getting the ocx drivers to work with the bar code scanner

Did you try the driversa I linked to above? They are your specific scanner, and the download includes a pretty thorough VB example.



 
robojeff recently said -
I know that this is most likely programmable but they need these to work in this fashion for other applications that they have.

He was refering to the tab character not the ocx, but once the scanner is configured to OPOS for the ocx, it will no longer do keyboard emulation(I'm pretty sure, but I don't have one on hand to test). Then it probably will not work on the "other applications", unless they are compatible with OPOS devices. So it seems best to forget about the OPOS ocx.

If their scanners insert a tab where yours does not, did you program your scanner to match their configuration, then try Ted's code?

Also, I'm not sure what you mean -

Even without breakpoints, an error is found and because there is actually an additional 8 or 9 fields on thie bar code seperated by tabs, that the error dialog box gets overwritten and I can't see what the error is or what is going on...

Are you saying the error pops up before the text box is is done recieving the data, causing the additional keystrokes to close the error dialog? If that is the case it sounds more like your trying to process the data before it is done being recieved. Show us the code you have. If you have the code in the change event it would try to process your code on every character recieved. You may need to put your code in the validate event or put in a timer to wait just a split second before processing. I think your error is because keyboard emulation is getting ugly. I just thought about this some more and it shouldn't close the error dialog unless there is a return character not a tab.

Tom
 
>Then it probably will not work on the "other applications",

Ah, yes - that is probably true.
 
I just noticed Ted's example does address the issue of testing to see if all the data has been recieved. So maybe you are counting the tabs then processing? And perhaps it is a return charater at then end of the data causing the error to close? Anyway post the code you went with so we can see what's happening.

Tom
 
Thanks for the all the input.. I have been trying your suggestions and will split up my observations below...

Regarding the Overrun problem:
I have tried both the keys up event and the after update event but I think what was happening was that the tabs in the bar code are stepping into other controls and the event is being entered while the bar code's stream of data is still being delivered. It appears that this is what is over writing the error information and actually adding data from its string into my code where I place a break point...

Both scanners output the same data to notepad
I tested both bar code scanners with the same bar code and they both output the same data into notepad. Also there are 8 tabs at the end of the data with no CRLF...

The same bar code scanned with both scanners gives different results in the text box:
The peculiar thing is that when I scan the same bar codes into a text box, the data looks different between the two scanners where one dumps the tabs and the other one does not.

I verified this by creating a form with a big text box and a command button. I only have a tab stop on the text box so that the data stream does not over write to the next control (command button).

The code in the command button is
Code:
a= Me.part (where part is the text box).

I set a break point on this and when I scan the new scanner (which inserts the tabs),

a = null

when I scan the same bar code with the original scanner (which does not input the tabs),

a = N269-569000WH1LOC08

which is the data of the bar code without the tabs...

This is very peculiar that both scanners will output the same to note pad but not to a text box...

TedSmith's test code
I would like to use Ted Smith's latest code recommendation but I am not sure what event to tie this into...

So I added a button with the following code:
Code:
Text = "N18-128200" & vbTab & "WH" & vbTab & "3" & vbTab & "LOC04" & vbTab & "1d2423" & vbCrLf
Me.box1 = Text

When I set the text box to this text string with this button and then click on my other command button,

a = N18-128200 WH
3 LOC04 1d2423

Short break from this project
I appreciate the help as I am trying to debug this at a customer's site in Ireland and will be travelling back to the states over the next few days and hope to find a scanner that mimics the behaviour of their scanner. I may have to break away from this for a few days for travel purposes, but I will return to address this soon.

I do appreciate your helpful suggestions !

cheers
 
Yes, a text box behaves differently to a label
A Label only needs vbCr to create a new line whereas a Text box needs vbCrLF to give a new line.

Also as said previously you have to set the text box Multiline property to True otherwise VbTab shows as a little black box instead of a few spaces.

Are you really sure the delimiter between items is a tab?
a = N269-569000WH1LOC08 would indicate that it is not rally a tab although it might produce a tab effect in notepad but not in a text box.

The sure way is examine each character.
Run this in the Immediate window straight after receiving a complete scan then breaking.
For a = 1 to len(box1.text):print a; mid(box1.text,a,1);ASC(mid(box1.text,a,1)):Next
You should get a 9 where ever there is a tab

1 N 78
2 1 49
3 8 56
4 - 45
5 1 49
6 2 50
7 8 56
8 2 50
9 0 48
10 0 48
11 9
12 W 87
13 H 72
14 9
15 3 51
16 9
17 L 76
18 O 79
19 C 67
20 0 48
21 4 52
22 9
23 1 49
24 d 100
25 2 50
26 4 52
27 2 50
28 3 51
29
13
30
10

This way you can see exactly what the difference is between the scanners and have a different code option preset if necessary for each scanner.

It then doesnt matter whether the scan has an end character or not.

I always believe in doing things simply so a sure way of getting the whole string is to have a small delay between when the first Item is received to when you actually use the data. This makes Vb6 wait long enough to cover the time it takes to read one barcode scan but fast enough to handle two reads in quick succession.

Put a timer on the form, set its Interval to say 100 (milliseconds) and set Enabled = false

(Increase this time if all the barcode is not read)

Then my previous example becomes

Code:
'Declarations
Dim Delimiter as String, a as Integer

Sub Form_Load
Delimiter=vbTab 'change this if the delimiter between items is different
End Sub

Sub TextInput_Change
Timer1.Enabled=True 'start the timer on the first bit of data
End Sub

Sub Timer1_OnTimer()
'happens 100 ms after the first character data is put into the text box thus allowing all the data to be read
DataCollected  'process the data
Timer1.Enabled=False ' stop the timer
TextInput.Text="" 'clear box ready for next read
End Sub

Private Sub DataCollected()
Dim X As String, MyString As String, Index As Integer
MyString = TextInput.Text 'puts data into a string
For a = 1 To Len(MyString)
    X = Mid(MyString, a, 1) 'examines each character of the string
    If X = Delimiter Then 'found a tab or whatever in the data
        Index = Index + 1 'step to next box
    Else
        If Index < 5 Then Text1(Index).Text = Text1(Index).Text & X 'put relevant data in the next box
    End If
Next
End Sub
 
Thanks Tedsmith-

I am back in t he office and have a scanner that is inserting the tabs but I am not able to set the text box to multi-line because it is not an option for the only text box that I have in my access 2003 controls.

I also attempted to find a "RichTextBox" but was unable to locate a control like this so I am still getting an over run data...

Once I find a richtextbox control capable of a multiline option, what event would I place the code for:

For a = 1 to len(box1.text):print a; mid(box1.text,a,1);ASC(mid(box1.text,a,1)):Next

 
Jeff, the code you have there is intended by Ted to show what characters (and the ascii values of them) are contained within your textbox. It needs to be run in the Immediate window (Ctrl+G) once you have received a full scan and paused code execution.

So you've looked all the way through the 'More Controls' pop up and not been able to locate 'Microsoft Rich Textbox Control 6.0' anywhere?

Andy
---------------------------------
[green]' Signature removed for testing purposes.[/green]

 
Thanks HarleyQuinn-

There isn't a 'Microsoft Rich textbox Control 6.0' in the more controls drop down box in my Access 2003...
Is this included in an additional service pack or downloaded from somewhere or is it supposed to be part of the typical Access 2003 package?

I tried Ted's code but when I scan the bar code into my text box, and have a break point on this code
(which by the way is set to the lost focus event), the over run of the bar code data gets inserted into my code where the break point is...

If I remove the breakpoint and scan the bar code, I get the following error:

run time error '438' Object does not support this property or method.

If I comment out all the code on the lost focus event and place this code on another
control (a button's click event) with a break point,
after scanning the bar code into the text box, I get a:
run time error '2185' you can't reference a property or method for a control unless the control has the focus.

My intent is to run this code and watch the intermediate window and I am not sure what event to use to capture this data while the control has focus and I
also believe that this might be possible with the multi rich textbox control but I do not currently have access to that control...

clear as mud, right?
 
There isn't a way to limit the data input into a text box to a certain length is there? If there was then perhaps the extra data would be ignored...

 
>Access 2003?


The richtextbox is supposed to ship with all the versions of Office (up to and including Office 2007), so you should have it available as far as I am aware. Perhaps it didn't register properly. Try the following when in Form Design mode

Tools/ActiveX Controls .../Register ...

Then browse to c:\windows\system32

and look for and select RICHTX32.OCX

OK your way back out. Now you should have the control available. Mind you, I'm not sure it is going to fix this.
 
Thanks strongm-

I tried this and could not locate richtx32.oc

I also tried to search my hard drive and could not find any "r*.ocx"

I did notice a thread where Bubba stated that rich text box was not supported with Access 2003



Is there another way to get this?
 
Bubba is incorrect (the problem mentioned in that thread is related to a security change that Microsoft made becasue they decided that the RTB was unsafe for scripting). However I guess that it is possible that the RTB is not shipped with standalone Access 2003, but only with the full Office.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top