Page state, buttons, and events
The previous page was view-only. This tutorial turns it into a safe front-end simulator with Start, Record package, and Stop. Page state belongs only to the current Page instance, so it is not confused with equipment state or durable data.
What you will accomplish
- Keep temporary Page-instance state in
$state. - Handle button events with ordinary TypeScript functions.
- Inspect the same Page source in Design and Source.
- Adjust one component style yourself.
- Verify interactions and refresh behavior in the runtime.
Before you start
- Complete Build your first runnable app with AI.
- Stop the current App.
- Make sure
pages/packaging-station.qpis saved and set as Home.
Step 1: Ask AI to add interactions
Record existing Git changes, open AI Command Center, select qxqp with @, and mention pages/packaging-station.qp. Send:
Goal: Turn the current Packaging Workstation QP home page into a front-end-only simulator.
Page state:
- let lineRunning = $state(false)
- let packCount = $state(0)
Interactions:
- Start simulation sets lineRunning to true
- Record package is enabled only while lineRunning is true and increments packCount
- Stop simulation sets lineRunning to false
- Status and count render directly from Page state
- Keep visible text in the current App i18n
Scope:
- Change only pages/packaging-station.qp and required `i18n.json` text
- Use the current Page event handlers, $state, and installed package components
- Do not change Variables, Objects, QG programs, C#, Pulsar, or Safety
- Clearly label every control as simulation-only
Validate QP and i18n, then report the state, functions, button events, and diagnostics.
Step 2: Inspect and refine
- In Design, select each button and confirm its Inspector event points to the intended function.
- In Source, confirm state uses
$stateand no button embeds equipment logic. - Return to Design, select the package-count component, increase its font size, and choose an accessible emphasis color.
- Save, run Build, and confirm Problems has no error that blocks the Page from running.
The data flow should remain clear:
Button event → Page function → $state → reactive interface update
Step 3: Run the acceptance check
- In the Page's Preview, select Start simulation and confirm that all three controls update the interface as expected.
- Select Build, then Start after deployment succeeds.
- Open the current runtime target's root address in a browser. The local default is
http://127.0.0.1:9210/. Do not append/api. - Select Record package three times; the count should be 3.
- Select Stop simulation; Record package should become unavailable.
- Refresh the page; state and count should return to their defaults.
That reset is expected because $state belongs to the current Page instance. Use an explicit App or Object storage capability for data that must survive navigation or restart.
Safety boundary
Page event functions coordinate UI only. Equipment batches, long waits, communications, motion, and safety interlocks belong in an engineer-approved Object or QG.
For recovery, mention the current file and send:
Analyze and fix only the current Problems diagnostics in @pages/packaging-station.qp.
Keep the existing layout and three simulation interactions. Do not add Objects, QG programs, C#, or persistence.
Validate again and explain the cause.
Next
The next tutorial moves the Page simulation into a debuggable QG Object: QG flow, Object calls, and Debug.