How to remove or deal with Linefeed/Carriage returns?

[Vita]

I tried to tackle this problem before but I feel like I have a better idea on how to do it now.
I have a bunch of barcodes that when scanned end with the following

 10 LF (linefeed)
 13 CR (carriage return)
 10 LF
 13 CR
 32 Space
 10 LF
 13 CR
 13 CR

Since Access likes to treat LF and CR like pressing the enter key I don't want it to automatically go to the next control on the form and press enter (since the next control is a button that updates records).
I was previously using an invisible control to handle that but it was not working the way I wanted.

The way I want it to work is that the user (and only the user) needs to press enter to move to the next control or click the button/next control. So I want to essentially nullify these LF's and CR's.
There are already thousands of these barcodes made up so I cannot change the barcode and they do not plan to.

There are 7 LF/CR's (I don't know why there is a space) so my idea is to on keypress get the ascii of the key as an int and use a select statement to count how many LF/CR's have been typed.
This part of the code seems to work but then it pushes the actual text up inside the textbox so I wanted to remove the LF/CR's.
I was thinking to use the code below but it just wants to delete some of the actual text instead of deleting the LF/CR.

Private Sub DhrScanTxt_KeyPress(KeyAscii As Integer)
Dim strCharacter As String
strCharacter = Form_Main.DhrScanTxt.Text
KeyPressed = KeyAscii
Debug.Print KeyAscii
If Not (IsNull(strCharacter) Or (strCharacter = "")) Then
    Select Case KeyAscii
    Case 10, 13
        iCount = iCount + 1
        Debug.Print iCount
        Form_Main.DhrScanTxt.Text = Replace(Form_Main.DhrScanTxt.Text, 0, (Len(Form_Main.DhrScanTxt.Text) - 1)) 'I tried using mid first.
        If iCount = 8 Then
            'Me.StepCompleteBttn.SetFocus
        End If
    End Select
End If
End Sub

Basically I was gonna have it count the LF/CR's so that it ignores the 7 from the barcode. That way when the user presses it, it will be the 8th time it will move the focus to the next control.
Any advice on how to accomplish this?

[Minty]

Why not get the user to press the tab key instead and you can then ignore the enter key completely? (in that control)

[CJ_London]

not really clear to me the situation - the implication is the user is effectively typing vertically. i.e. user type A>return>B>return>etc. or once scanned, the data is displayed vertically. Or it could be a setting on your scanner? Can you describe what the user is actually doing and what is actually required to happen

[Minty]

@CJ - From memory I think the barcode reader interprets some of the end of the barcode as a series of LF's & carriage returns (and a random space!)

[Micron]

I'm not really following. User is putting the cr & lf into the field or the scanner is doing that? Or both?
You could trap the enter key and if you want to negate it, IIRC you set KeyAscii to zero. You could then move the focus based on that.
If you're wanting to remove existing line wrap characters you'd use an update query with Replace function. I don't think I'd involve a count (as done in that code) but I don't really see its purpose (as noted, not following 100%). What happens if the powers that be decide another character is needed?

[Minty]

I'll chime in as I remember the last thread on the subject.

The End user scans a barcodes, part of that scan includes multiple "Enter" key codes, that obviously would either trigger the control to shift focus to the next control(s) on the form or in this case get entered as multiple carriage returns in the data, as the text box control is set to do that rather than move to the next control.

[Vita]

I'll chime in as I remember the last thread on the subject.

The End user scans a barcodes, part of that scan includes multiple "Enter" key codes, that obviously would either trigger the control to shift focus to the next control(s) on the form or in this case get entered as multiple carriage returns in the data, as the text box control is set to do that rather than move to the next control.

Correct I believe?

Why not get the user to press the tab key instead and you can then ignore the enter key completely? (in that control)

The enter key behavior was set to default. In access default behavior for enter key is to treat it like tab.

not really clear to me the situation - the implication is the user is effectively typing vertically. i.e. user type A>return>B>return>etc. or once scanned, the data is displayed vertically. Or it could be a setting on your scanner? Can you describe what the user is actually doing and what is actually required to happen

The user is scanning a barcode. I had VBA print out each character of the barcode as ASCII and that's what the vertical text is. I just trimmed it so it is only showing the end of it. Here is the full with some pipes to hopefully make it a bit clearer:

 ascii | value
 50 | 2
 54 | 6
 50 | 2
 50 | 2
 54 | 6
 57 | 9
 45 | -
 49 | 1
 52 | 4
 45 | -
 48 | 0
 49 | 1
 48 | 0
 10 | LF (linefeed)
 13 | CR (carriage return)
 10 | LF
 13 | CR
 32 | Space
 10 | LF
 13 | CR
 13 | CR

or "262269-14-010" with 7 empty lines.

I'm not really following. User is putting the cr & lf into the field or the scanner is doing that? Or both?
You could trap the enter key and if you want to negate it, IIRC you set KeyAscii to zero. You could then move the focus based on that.
If you're wanting to remove existing line wrap characters you'd use an update query with Replace function. I don't think I'd involve a count (as done in that code) but I don't really see its purpose (as noted, not following 100%). What happens if the powers that be decide another character is needed?

Basically this is how the program should work.
1. User clicks/enters the textbox
2. User scans barcode (or types it in manually)
3. User either clicks the button or (for keyboard only compatibility) presses the enter key twice (once to confirm they are done entering the workticket numbers and once to "click" the button to update)
4. The form clears itself and runs again.

I am trying to write code to deal with the fact that the barcodes have LF and CR inside them.
In retrospect upon typing this I realize if they user were to type it in manually they would have to press enter 7 times.
I am not sure how to handle this issue though.

I changed the enter keys behavior to create a new line instead of the default(acting as tab) so that VBA can pickup the key being pressed/typed so that I could attempt to stop it from automatically going to the button, pressing enter, which would cause the record to be updated. (I don't want this to be automated. I want the user to have to press enter or click 'complete'.)

Hope this clears things up.

[Minty]

So would it matter if they have to click complete, and NOT press enter?
The tab key method should work or you could check for it?

If that is allowable it's simple your Continue Button simply truncates the data in the text box from the first LF character.

[Vita]

So would it matter if they have to click complete, and NOT press enter?
The tab key method should work or you could check for it?

If that is allowable it's simple your Continue Button simply truncates the data in the text box from the first LF character.

The tab key method worked partially. There was an issue with if 2 barcodes got scanned consecutively then it would automatically update the previous scan.
Scanning the second barcode would click the complete/continue button AND click the yes button on the confirmation pop up.
It would be nice if I could just make the LF/CR are useless.
The ideal functionality would be 2 different routes because sometimes the barcodes get wet or cant be scanned so we have to type them in manually.
Barcode route would scan the barcode in and run all the code I wrote to populate the captions with data relevant to the ticket. (all in the after update statement)
While Manually entering the data would require you to press enter twice or tab then enter. The first enter/tab being to move to the next control and the second to press said control/button.

So I guess the Tab key would work but the double scanning is an issue. Is there anyway to get Access to differentiate between someone pressing Enter and a LF/CR?
Sometime (like 1/20 chance) the scanners just double scan a barcode due to the amount of time they stay on when pressing the button.

I apologize that this is so complicated and for my poor explaining.

[Micron]

Is there anyway to get Access to differentiate between someone pressing Enter and a LF/CR

Doesn't this fill that need in at least one case?

You could trap the enter key and if you want to negate it, IIRC you set KeyAscii to zero.

If the code contains cr & lf's why not let the record update, then remove the characters from the record immediately?

[Vita]

Doesn't this fill that need in at least one case?
If I trap the Enter key then they would have to manually click the complete button right? or use Tab to get to the next control?

If the code contains cr & lf's why not let the record update, then remove the characters from the record immediately?

The code doesn't contain CR & LF, It is just the barcode. It's an odd system but the information that the barcode inputs is not actually going into a table. It is the primary key (well 3 added up. The hyphens separate them) of the table.
In the after update event I have code that uses the barcode information to find the relevant record and display information about that record in some captions so the user can confirm view it and confirm.
Upon clicking the complete button it uses a few update queries to update information on that record (EX: status changes from 'NEW' to 'COM' and the Time/date updated fields get the time and date input)

So the first LF/CR is fine because it should be signifying that the barcode is done typing the primary keys. (or the user hitting enter would signify they are done doing so) but I need a way to trap/ignore the other 6 LF/CR.

When you press enter or click the "Complete" button, if the status of the order is set to 'COM' a pop up appears asking you to confirm you want to mark it complete (because sometimes human error and the time/user who did it needs to be reupdated)
If the status is 'NEW' then it does not ask this.
Problem is since access treats LR/CR as Enter, if you accidentally double scan a barcode the numbers will have nowhere to go but when it gets to the LR/CR it will move to the complete button, press it, and confirm it if required. Updating the record even if the user did not want to and only wanted to view information about it. (say they wanted to see when it was completed or they scanned the wrong one by accident and it double scans)

I suppose I could remove the complete button from the tab index but then you can no longer tab to it and are required to have a working mouse which isn't a huge deal nowadays anyways but I am looking for a way to have both.

[Micron]

The code doesn't contain CR & LF

I meant the bar code.

It is the primary key (well 3 added up.

Seldom a good idea to use meaningful data as the PK
As for the rest, I'll admit I have no experience using a scanner so I think I will disengage.

[Vita]

I meant the bar code.
Seldom a good idea to use meaningful data as the PK
As for the rest, I'll admit I have no experience using a scanner so I think I will disengage.

Its not a good idea to use a work order number as a PK? or what do you mean by meaningful data and why not? (Not that I have a say. Its an existing system)

[moke123]

Its not a good idea to use a work order number as a PK?

Is that what is contained in the barcode? And it's being modified?
What happens if work order number is modified in some way not in your control or if its repeated after a number of years?

There are a lot of discussions on this subject with differing opinions. Google it.

Personally I always use an autonumber as there is no question as to its uniqueness.

[Micron]

here's a couple
http://access.mvps.org/access/general/gen0025.htm
https://www.fmsinc.com/free/newtips/PrimaryKey.asp

EDIT-

Not that I have a say.

I think you do. Adding an autonumber field to your table is easy in the beginning, but may be a challenge when there is existing data in related tables. Still possible to fix though. Question is, do you have the motivation to prevent an issue, especially if it hasn't raised its ugly head yet.