Barcode scanner appends to the previous value: fix it with selectAll

A handheld or fixed code reader in keyboard mode types each scan into whatever field has focus. When that field is a reused entry box, the new code lands after the old one — 1234 followed by 5678 shows 12345678 — and the operator starts correcting values by hand. This guide fixes the receiving side. You will make every scan replace the previous value with a two-line focus-and-select script, defer the selection past the client's own caret work so the fix holds scan after scan, keep the previous scan in a second field, and verify the whole loop with four scans and no mouse.

Why does a new barcode append to the previous value?

Because the entry field still holds the previous scan with the caret sitting after its last digit, so the scanner's keystrokes are inserted there: 1234 followed by 5678 becomes 12345678, an 8-digit value built from a 4-digit scan plus a 4-digit scan.

A keyboard-mode reader is a keyboard as far as the client is concerned. Each scan types the decoded digits, plus any configured suffix, into the focused component at the caret. Between scans the field never loses focus and nothing tells it to release the old text, so every new scan is typed in rather than entered fresh.

A Carriage Return suffix does not rescue this on its own. It commits the field's value, which is what fires the value-change event you script against, but the committed text stays in the box with the caret after it. Committing and clearing are two different actions, and only one of them belongs to the suffix.

Why does setting focus alone not fix it?

requestFocusInWindow() only moves keyboard focus back to the field; it changes neither the caret position nor the selection, so the next scan is still inserted at the end of the old text. You need focus and a full selection together before the next keystrokes arrive.

The mechanics are the ones you use by hand: click into the field and select everything (Ctrl+A on most desktops) before scanning, and the first digit of the new code deletes the selection and types over it. Focus gives you the caret; the selection is what gets replaced. So the script needs a second call on the same component, and in a Java Swing desktop client every text field already carries it — selectAll() is a standard method of the toolkit, sitting alongside requestFocusInWindow(), even where your vendor's manual documents only its own properties. The related failure, focus landing on the wrong component after a scan, is covered in the keyboard wedge focus guide.

What do I need before I change the script?

Three things: scripting access to the field's property-change event in the client, a scanner that sends keystrokes to that client, and four test codes — four, because the failure being fixed shows up on alternating scans and hides behind a two-scan test.

Scripting access means you can open the component's event script and edit the branch keyed on the changed property. The numeric entry field in this pattern reports its property as "longValue"; a plain text field reports a different property name, so check what your field actually fires before copying anything.

Scanner side, the connection mode decides whether the fix applies at all. In HID keyboard mode over USB the reader types into the focused field like a keyboard, which the HMI input-mode comparison sets against serial mode. Over serial or Fast Ethernet the string goes to a host program instead and there is no field to repair; that path is the reader as TCP server with the PLC as client.

If you are choosing the scanner as well, the shop's wired USB handheld code readers:

How do I make every scan replace the field's contents?

Add selectAll() to the same property-change branch that sets focus, so the script reads: on a change of the field's value property, pull focus back and select all existing text; the first digit of the next scan then overwrites the whole selection.

1. Open the property-change script on the entry field in the client's scripting editor.
2. Keep the branch keyed on the value property your field reports — event.propertyName == "longValue" for the numeric field in this pattern.
3. Add event.source.selectAll() directly under event.source.requestFocusInWindow().
4. Save and scan two codes; the field must hold only the second code.

if event.propertyName == "longValue":
    event.source.requestFocusInWindow()
    event.source.selectAll()

Both calls act on the same component, in order, inside one event dispatch. On a quiet client this alone holds all day. On a typical station it holds every second scan, which is the next problem.

Why does the fix skip every second scan?

Because the selection is being wiped by work the client still has queued: focus and caret updates from the scan land after your selectAll() runs, and whether that queue is busy alternates from scan to scan — so the fix holds on one scan, fails on the next, and repeats.

The reader sends the whole code as keystrokes inside a few tens of milliseconds. Your script runs in the middle of that burst, while the client is still moving focus, restoring the caret and repainting the field; a selection made mid-stream can be discarded before the last keystroke lands. Hand the selection to the end of the queue instead: system.util.invokeLater(call, delay in ms) runs your function on the GUI thread once the delay elapses.

if event.propertyName == "longValue":
    event.source.requestFocusInWindow()
    system.util.invokeLater(event.source.selectAll, 50)

Start at 50 ms. If a scan still appends, step the delay up 50 ms at a time — 100, 150, 200 ms — and stop at the first value where four consecutive scans all replace. A desktop client rendering a busy window commonly needs 100-200 ms; the right number is the smallest delay that passes the four-scan test, not the largest you can type.

if event.propertyName == "longValue":
    def refocusAndSelect():
        event.source.requestFocusInWindow()
        event.source.selectAll()
    system.util.invokeLater(refocusAndSelect, 100)

refocusAndSelect is this example's own function name. Moving the focus call into the deferred block covers the stubborn case: focus lands, the client finishes its own caret work, and only then is the full selection made — one queue position after everything else the scan triggered.

How do I keep the previous scan in a second field?

Copy the old value before it is overwritten: give the field a custom property that remembers the last scan, write that memory into field 2 inside the same property-change script, then update it to the new scan — the first scan must be guarded because the memory starts empty.

if event.propertyName == "longValue":
    previousScan = event.source.lastScan   # str, custom property on this field, initial ""
    if previousScan != "":
        pass  # write previousScan to field 2 here with your usual scripted value write
    event.source.lastScan = str(event.source.longValue)
    event.source.requestFocusInWindow()
    system.util.invokeLater(event.source.selectAll, 50)

lastScan and previousScan are this example's own names: lastScan is a text custom property you add to the field with an empty string as its initial value, and previousScan is the local string holding it for the current event. The guard matters. The first scan has no predecessor, and writing an empty string into field 2 is exactly the quiet first-scan failure described in the null previousValue fix.

With the selectAll fix in place the field only ever holds one scan, so one memory property buys one generation of history. For a running trail, route each scan into its own field or row, as in the two scans into separate HMI fields guide. If the scans land in a PLC instead of an HMI field, the same keep-the-previous-value discipline lives in ladder: this ladder-logic walkthrough that keeps the previous integer value shows the pattern.

Can the scanner itself be set up to avoid this?

Only partly: a Carriage Return (CR) or Tab suffix makes each scan commit or advance, which suits multi-field forms, but the suffix cannot clear a single reused field — when you cannot script the client, let the commit action clear it.

Suffixes are configured in the reader, not the client. CR submits the field the cursor is on; Tab moves focus to the next one. Where each scan belongs in a different box, that is the cleaner design — scan one into field 1, scan two into field 2, no scripting at all. The framing characters around the payload are detailed in the prefix and suffix framing guide, and codes of unpredictable length in the variable-length input fix.

For one field reused all shift — the loop above — the suffix has nowhere to advance, so the field-side script stays the answer. On the line rather than the desk, fixed code readers skip fields entirely: a fixed code reader sends each decode to a host program over its network or serial link, like this Fast Ethernet compact model:

How do I verify the fix holds scan after scan?

Clear the field, scan four codes in a row and check two things after each scan: field 1 holds only the newest code and field 2 the one before it — four clean passes with no clicks in between clear the station for the shift.

1. Erase field 1 with your normal clear routine, then hands off the mouse.
2. Scan code A. Field 1 shows A and field 2 stays empty — the guarded first scan.
3. Scan code B. Field 1 shows only B; field 2 shows A.
4. Scan C, then D. The rule holds each time: newest in field 1, predecessor in field 2.
5. If any scan appends, raise the defer in 50 ms steps from 50 to 200 ms and repeat all four scans.

The whole fix is two calls and a delay: focus, select everything, and let the queue drain first. Match a reader to your symbology and distance in the code reader finder, or send a photo of the code and the working distance through the contact page and we will help you spec the station.