Why Won't Ignition 8.3 Form Focus Follow Barcode Scans?

The panel accepts the barcode into the active Form field, then leaves the cursor there; on first opening, no internal field is active at all. Calling focus() on the Ignition 8.3 Perspective Form cannot select one of its internal widgets. For deterministic startup focus and scan-to-scan progression, use independently addressable input components or make the scanner generate a navigation keystroke that the Form recognizes. A delayed focus call helps only when it runs on the actual focusable input, not on the Form container.

Read the symptoms before changing the project

Start here. Separate the two failures because they occur at different layers:

Confirm that the barcode value is complete before investigating focus. Missing or truncated data is an input-delivery problem, not a focus problem.

Distinguish Form focus from field focus

The Form presents fields as widgets, but those widgets are not equivalent to separately placed Perspective input components. A focus request against the Form addresses the outer component. It has no supported instruction telling it which internal widget should receive the caret.

This call therefore targets the wrong object:

def runAction(self, event):
    self.getSibling("Form").focus()

Walking through props.columns.items, rows.items, and widgets does not solve that boundary. Those properties describe the Form configuration. The returned scripting object has no focus() method, which produces:

AttributeError: 'com.inductiveautomation.perspective.gateway.script' object has no attribute 'focus'

Changing tabIndex may alter traversal among elements the browser already treats as focusable. It does not create a callable internal component or make Form-level focus() delegate to a chosen widget. That is not the fault to chase first.

Trace the scanner suffix through Android

A keyboard wedge normally submits characters through the active Android input path. Barcode data and its configured suffix can still be handled differently from a physical keyboard key event. A literal carriage return, \r, may complete the scan without producing the keydown/navigation behavior the Form uses for Enter or Tab traversal.

Run these checks in order:

1. Tap the first Form field and type with the regular keyboard. Record what Enter does and what Tab does.
2. Scan the same value with the scanner configured to append \r. Confirm whether the suffix advances focus, remains in the value, or disappears without navigation.
3. If the scanner configuration supports it, test a Tab suffix. Use the device configuration interface rather than embedding control characters in the barcode.
4. Repeat the test in the same Perspective session and Android input configuration used by operators. A desktop-browser result does not prove how the integrated scanner service delivers the suffix.

If a scanner-generated Tab advances the Form exactly once, keep the Form and validate every field transition. If neither supported suffix creates a navigation event, further Form-level focus calls waste time.

Build a controllable focus procedure

Use independently addressable text input components when the workflow requires an exact first field and an exact next field. Each input can then own its focus behavior and react to a view message without relying on layout-relative paths.

1. Replace each scan-critical Form widget with a standalone text input component. Keep the Form only for fields that do not require scripted focus.
2. Place the startup handler on the first actual input. If rendering races the startup event, use the documented workaround shown below and verify the delay on the target device.
3. After accepting and validating a scan, call system.perspective.sendMessage() to request focus for the next input.
4. Add a message handler to each destination input. Have that component call self.focus() on itself.
5. Keep navigation names independent of component ancestry. Do not use getSibling(), getChild(), or getParent() chains for this workflow; rearranging the layout breaks those paths.

def runAction(self):
    import time
    time.sleep(0.5)  # wait half a second
    self.focus()

The 0.5-second delay is a render-timing workaround, not a Form feature. Apply it only to the focusable input component. A fixed sleep can become unreliable when device load, network latency, or view complexity changes, so prefer a component-owned message after the destination exists.

Verify the complete scan sequence

Test the behavior as an operator uses it, not one field at a time:

1. Open the view without touching the screen. Confirm that the caret appears in the intended first standalone input.
2. Scan a valid barcode. Confirm that the stored value matches the barcode and excludes the navigation suffix.
3. Confirm that focus moves once to the intended next input. It must not remain behind or skip a field.
4. Scan through the entire sequence, including validation failures, blank scans, duplicate scans, and a rescan of the current field.
5. Close and reopen the view several times. Startup focus must survive both fast and slow rendering.
6. Repeat on the Honeywell CT37 with the production scanner profile. Verify both soft-keyboard and integrated-scanner behavior.

For an offline workflow, disable any expectation that UI event scripts will manage focus. The message-handler design and scripted self.focus() calls require online UI scripting. Offline operation must rely on native component navigation and the scanner’s delivered key behavior, or the screen architecture must change.

Avoid the fixes that repeatedly fail

• Sleeping and then focusing the Form: the delay may solve render timing, but the target remains the non-delegating Form container.
• Calling a widget through the Form property tree: a widget configuration object is not a component instance and exposes no focus().
• Changing every tabIndex value: traversal order cannot provide direct scripted access to an internal widget.
• Assuming \r equals keyboard Enter: verify the event delivered by the Android scanner path. Identical characters do not guarantee identical navigation events.
• Depending on layout-relative component paths: moving a container or input silently invalidates the script.
• Designing scripted focus for offline mode: UI event scripts do not execute there.

FAQ