Route the camera scan through a page-bound handler. The session barcode event can classify the barcode, but the open page must execute system.perspective.openPopup(). This preserves the working popup logic while supplying the page context that the session event lacks.
Where does the popup request stop?
Follow the packet. The phone camera delivers barcode data to the session barcode event. That event runs in session context, where it can read the barcode and select a popup. The request fails only when it tries to perform a page operation from a thread without an attached Perspective page.
| Path stage | Context | Expected reading | Meaning |
|---|---|---|---|
| Phone camera | Device | A barcode value reaches the session event | Image capture and barcode decoding are working |
| Session barcode event | Session | Selection logic produces the intended popup choice | The event and routing logic are working |
| Popup call | Page |
system.perspective.openPopup() reports that no Perspective page is attached to the thread |
The call lacks page context |
| Root view handler | Open page | The handler receives the routed payload | The request has crossed into a page-bound execution context |
No network address or TCP/UDP port is implicated by this symptom. The break occurs at the execution-context boundary inside the application: a session-scoped producer is attempting to invoke a page-scoped operation.
Does the barcode reach the application?
Layer one first. Confirm that the camera scan actually fires the session barcode event before changing popup code. Record the decoded value at the start of the event and the popup selection produced by the existing decision logic.
- Scan a barcode that maps to a known popup.
- Confirm that the session event receives the complete barcode value.
- Confirm that the decision branch selects the expected popup.
- Stop here if either value is missing or incorrect; the fault is in capture, decoding, or selection logic rather than page context.
- Continue to the context check only when both readings are correct.
The existing BarcodeScannerInput path provides a useful control test. Its onActionPerformed script already opens the popups successfully, proving that the popup definitions and page-side logic can work. The material difference is where the event executes: the component event belongs to an open view, while the camera barcode event belongs to the session.
Does the call fail only from the session event?
Run the same barcode choice through both paths and compare the result. This separates a bad popup selection from a missing page attachment.
| Test | Popup choice | Result | Next check |
|---|---|---|---|
BarcodeScannerInput onActionPerformed
|
Correct | Popup opens | Test the session event with the same value |
| Session barcode event | Correct | No-page-attached error | Move the popup call to a page handler |
| Either path | Incorrect | Wrong popup or no request | Correct the barcode-to-popup selection logic |
| Page handler | Correct | Handler receives nothing | Check message delivery and handler placement |
The error text identifies the failed hop: system.perspective.openPopup() is executing before the request reaches an open page. Repeating the call from the same session event does not add page context.
Which session-to-page bridge fits the application?
Use a bridge that terminates inside the open view. Three patterns are available, but the message-handler pattern keeps the barcode decision in the session event and the visual action in the page.
| Pattern | Session-side action | Page-side action | Use when |
|---|---|---|---|
| Perspective message | Call system.perspective.sendMessage() with a payload describing the selected popup |
A root view script message handler calls system.perspective.openPopup()
|
The open view should react immediately to each scan |
| Session property binding | Write the scan result or popup choice to a session property | Bind a view custom property to it and open the popup from a change script | The value must also remain available as session state |
| Explicit page targeting | Use system.perspective.getSessionInfo(), filter to the project, select the session by ID, and read its pageids
|
Pass the selected page target through the optional arguments of system.perspective.openPopup()
|
The application has a reliable rule for choosing among open pages |
Explicit targeting needs an unambiguous destination. A session may expose multiple values in pageids; selecting an arbitrary entry can send the popup to the wrong page. The message-handler approach makes the receiving view the destination and avoids moving page-selection policy into the barcode event.
How should the message-handler fix be configured?
- Keep barcode parsing and popup-selection logic in the session barcode event. Its output should identify the desired popup and contain only the data the page needs.
- Build a payload from that result. Preserve the barcode value if the popup consumes it, and preserve the selected popup choice so the view does not have to duplicate the decision tree.
- Send the request with
system.perspective.sendMessage(). Use the actual function name;system.perspective.message()is not the corrected API call identified for this solution. - Add a script message handler to the root of the view that is open during scanning. The handler must receive the payload in page context.
- Validate the payload before opening anything. Reject a missing or unknown popup choice instead of falling through to an unrelated popup.
- Move the
system.perspective.openPopup()call into that root handler. Pass the popup choice and required barcode data from the received payload. - Remove the direct popup call from the session barcode event so that only the page-bound handler owns the visual action.
Keep the ownership boundary clear: the session event decides what the scan means; the view decides what appears on its page. If several possible popups exist, use one page-side dispatch block so every accepted choice follows the same validation and opening path.
How do you verify the resolving branch?
- Open the target view before starting the scan.
- Scan one known barcode for each popup-selection branch.
- For every scan, record four checkpoints: barcode received, popup choice selected, payload received by the root handler, and popup opened.
- Scan an unknown barcode and confirm that no unrelated popup opens.
- Close the target page and scan again. No popup can appear without an open receiving page; handle that condition as an expected routing outcome.
- Reopen the page and repeat the known scan. Confirm that one scan produces one handler execution and the intended popup.
If duplicate popups appear, look for multiple active handlers, repeated message sends, or both the old direct call and the new handler call remaining active. If the handler receives the payload but no popup appears, inspect the handler’s dispatch value and its local system.perspective.openPopup() call. If no payload arrives, inspect the message routing configuration and confirm that the handler is attached to the currently open root view.
FAQ
What happens if system.perspective.openPopup() runs in a session barcode event?
The call can report that no Perspective page is attached to the thread because the session event has no implicit page context. Send the result to an open view and call system.perspective.openPopup() from its handler.
What happens if the phone scans correctly but no message reaches the view?
Check that the session event calls system.perspective.sendMessage(), that the root view contains the matching script message handler, and that the view is open when the scan occurs.
What happens if more than one Perspective page is open?
An explicit-target solution must choose the correct value from pageids. Use a root view handler when the receiving view itself should define the destination.
What happens if a session property is used instead of a message?
Bind a custom property on the open view to that session property, then call system.perspective.openPopup() from the custom property’s change script. Account for repeated scans that write the same value and therefore may not produce a change.
What happens if the popup opens twice after the fix?
Check for duplicate root handlers, repeated system.perspective.sendMessage() calls, or a remaining direct popup call. Verify the final state by scanning once and confirming one payload reception, one handler execution, and one popup.