Two windows, one scanner, and every scan lands in the wrong handler. You build an operator client with a barcode component on a docked login window, add a second component on an administration or process window, and the second one never fires. The reader beeps and the decode rate looks fine, so the optics are innocent: the failure is input routing. The sections below explain why the first listener owns the stream, how to prove which one holds it in five minutes, and three ways to route scans — one active listener, prefix routing, or separate hardware — with a decision rule for each case.
The symptom: only the first listener ever decodes
Window A decodes normally. Open window B with its own listener and scan, and the frame still arrives in A — sometimes while B is the window on top. Disabling the component you do not need, or setting its visible property false, often changes nothing, because those flags control display rather than input ownership.
The failure sits one layer above decoding. When codes fail to read, the reader stays silent; here it beeps, so a decode exists and only the delivery is wrong. If your codes are actually silent or damaged, work the contrast problem first — see improving decode rate on damaged, low-contrast codes. Everything below assumes a healthy decode and a stolen stream.
Routing questions like this one belong to the code-reading topic, alongside the decode-side guides.
One scanner has one owner
Every transport a code reader speaks allows exactly one consumer at a time. The three input paths — serial, USB and Ethernet — each carry their own contention rule:
- Serial (RS-232): the operating system grants one open handle per COM port. The first listener's open succeeds; the second gets an access error or never sees a byte.
- USB keyboard wedge: the scanner types into whichever window holds keyboard focus. A listener that installs a global hook instead takes every scan from every window, which is how one docked component eats scans aimed anywhere. The wedge mechanics are spelled out in the keyboard wedge guide for HMIs.
- Network: the reader pushes frames to one configured address and port, and one program binds that port. A second listener cannot bind it while the first holds it; check which side should be client and which listener before you assume contention — the TCP client or listener guide covers the match.
On top of the transport sits the framework layer. Many clients instantiate every window's components at start-up, so the first-registered listener claims the input and the others idle forever. An enabled property on the idle component does not close the winner's handle; only a real shutdown does.
One trap catches careful builders: some frameworks match open windows by name or title, so two windows with the same title can end up sharing one instance. Navigation swaps the content, the first listener stays alive, and your open-and-close logic never runs. Give every window a unique name and a unique title.
Find the owner in five minutes
Work down the list in this order; the first test usually ends the hunt.
- Log the opens. Add one log line where each component opens its input, restart the client, and read which name opened first. First open wins the port, the device or the socket.
- Truly close the first window. Close and destroy window A — not minimize, not hide — then scan. If B fires, contention is confirmed and the cure is lifecycle management.
- Try the port from outside. With the client running, open the same serial port from a terminal program. An access error proves the client still holds it; no error points to focus or the socket instead.
- Click and scan. Put the cursor in a text field on window B and scan. Data landing only there means focus is doing the routing and no global hook is installed.
- Compare names. Check both windows' names and titles for duplicates, because identical names let the client reuse one instance and leave the first listener running.
In order of probability: first-open ownership, then keyboard focus, then duplicate window names.
Fix 1: one active listener, opened and closed with its window
When the two duties never overlap — badge login versus an administration screen — the cheapest cure is to let exactly one listener exist at a time. Open the input in the window's open event, shut it down in the close event, and never let two windows own the input at once. Hidden is not closed: a minimized or hidden window keeps its handle, so the shutdown call belongs in the real close path. Closing and reopening cleanly also prevents the silent data loss described in the serial port close and reopen guide.
Where your platform offers a retargeting call that swaps a shared window's content instead of stacking a duplicate, take that path so only one instance ever exists.
Verify with navigation: walk every window change 20 times, scan each time, and require exactly 20 decodes, all in the active handler, with zero orphan events in the log. A 21st event means a second listener is still alive — go find its open call.
A compact USB reader covers single-owner duty:
- Resolution
- Up to 3 MP
- Shutter
- Global
- Interface
- USB
Fix 2: one always-on listener, routed by prefix
When the duties can overlap — an always-on login listener on a docked window plus occasional admin popups — stop switching and route instead. Keep exactly one component alive for the whole client session and encode the destination into the frame:
| First character | Route | Handler |
|---|---|---|
| A | badge login | session log-in script |
| U | user administration | user-management window |
| P | process or job data | recipe field on the active screen |
Print the prefix into the label or configure the reader to prepend it, and let one script read the first character, strip it and dispatch the rest. Pick a character that never appears in the payload: if your codes are numeric, any letter is free.
Because nothing opens or closes, concurrent windows cannot starve each other. The routing cost is small. With example link settings of 9600 baud, 8 data bits, no parity and 1 stop bit, a serial link moves 9600 bits/s ÷ 10 bits per character = 960 characters per second, so a 14-character frame — 1 prefix, 12 payload characters, 1 terminator — takes 14 characters ÷ 960 characters/s = 0.0146 s, about 14.6 ms on the wire. Budget 5 ms for the dispatch script and the whole detour is roughly 20 ms, about 2% of a one-second operator cycle.
Start and stop characters, terminators and preamble stripping are covered in the prefix and suffix framing guide, and payload parsing with capture groups in the regex parsing guide.
Wired handheld readers come in USB and Ethernet versions, and either can own the always-on login listener:
- Interface
- USB
- Connection
- Wired
- Interface
- Fast Ethernet
- Connection
- Wired
Fix 3: separate hardware for simultaneous work
Some work is genuinely parallel: two stations, two operators, scans arriving at random moments. One scanner stream cannot serve two independent listeners, so stop sharing. Give each destination its own reader, or give one reader two fully separate outputs.
At the data layer a network reader still talks to one socket; if two programs really need the same reader, let one small forwarder service own the connection and dispatch frames by rule. At the wiring layer, a reader with a discrete output can steer its single 24 V result line to one of two destination inputs through relay or transistor logic — the transistor version is laid out in routing a 24 V supply to one of two outputs with a BJT.
Garbage frames after wiring changes are their own diagnosis — see the serial garbage characters guide. For a fixed station on the plant network, choose a reader that pushes frames over Ethernet:
- Resolution
- Up to 3 MP
- Shutter
- Global
- Interface
- Ethernet
Choosing between the three fixes
Match the pattern to the duty calendar:
| Situation | Fix | Why it fits |
|---|---|---|
| Duties never overlap, for example login versus an admin screen | 1 — one active listener | no label, script or hardware changes |
| One always-on duty plus occasional screens, possibly open at once | 2 — prefix routing | concurrent windows safe; needs a route key and one dispatch script |
| Two stations working at the same time | 3 — separate hardware | the only option with true parallelism |
The edge case that decides it: when two windows must react to different codes that can arrive at any moment, Fix 1 fails no matter how cleanly the windows close, because the duties are concurrent by definition. Route by prefix or add hardware. When the second duty is occasional and human-paced, Fix 1 costs less code and Fix 2 costs less ceremony: take Fix 1 if navigation already runs through a close event, Fix 2 if windows stack up.
Prevent it on the next project
Build the routing rules in before the first window exists:
- One owner per input. A serial handle, a claimed USB device or a bound socket serves exactly one listener; write the ownership into the design.
- Unique window names and titles, even when two layouts look the same — name reuse is what leaves a zombie listener alive.
- Enabled and visible are display state. Input release happens in the close event, not in a property change.
- One handler for every scan, logging raw frame, timestamp and chosen destination, so an orphan hunt takes minutes instead of an evening.
- Keep decode and routing separate. A stolen stream is a routing bug even when every decode is healthy.
Commissioning test: scan 20 times across every navigation path in the client and require exactly 20 logged events, each with a destination. Anything less means a listener is still contending.
When the same scan also feeds a PLC tag or a database, duplicates and missed change events can appear at the data layer; forcing OPC UA tag change events on duplicate barcode scans covers that side.
To pick the hardware end of the chain, browse the fixed code readers and handheld code readers categories, narrow the field in the code reader finder, or start the system configurator to match reader, connection and destination. If the routing design is still open, describe your window layout through the contact page and we will help you choose.
Questions
Can two programs share one barcode scanner at the same time?
Not directly on one input. A serial port allows a single open handle, a network reader pushes to one socket, and a keyboard-wedge scanner types into whichever window holds focus. To share one reader, let one program own the input and forward decoded payloads to the second program, or route by a leading prefix character. For genuinely simultaneous scanning, hang a second reader on the second destination.
Why does the reader beep but no window shows a scan?
The beep usually confirms a decode, so the data exists and only the delivery failed. Check where it went: a hidden window's listener may still hold the port, a keyboard-wedge scan may have landed in a control that consumed the keystrokes silently, or a serial command link may be eating frames. Log every raw frame with a timestamp at one place, and the missing destination becomes obvious in one scan.
How do I route scans between two windows without reprinting the labels?
Use differences that cost nothing to change. Configure the reader to prepend its own prefix per job, so frames differ even though labels do not; route by symbology when the two duties use different code types; or route by keyboard focus with a wedge scanner and accept its limits. Only when none of these applies do you need the stricter one-listener-at-a-time pattern.
Does hiding or disabling a window release its barcode listener?
Usually not. A hidden or minimized window's component can keep its port handle or keyboard hook alive, and an enabled or visible property alone does not close the input. Release needs a real shutdown: close and destroy the window or call the component's shutdown routine, then prove it by opening the same port from a terminal program with no access error.