Build and runtime acceptance

Editor Build checks the project saved on disk and deploys a runnable version to the current Runtime target. A successful Build does not mean the App has started; use Start or Debug afterward.

Goals

After reading this page, you should be able to:

• decide whether a change requires another Build;
• choose Build Debug or Build Release;
• build independently or use Build and continue when Start or Debug asks;
• diagnose delivery failures from Problems, runtime state, and target information.

Where to work

Task	Entry point
Select a Runtime target	Left of Build in the editor toolbar
Build with the previously selected Profile	Toolbar Build
Build, run, or manage the target from the native menu	Menu bar Run
Select Debug or Release explicitly	Menu to the right of Build
Clean the local Build result	Clean in the Build menu
Start or debug	Toolbar Start / Debug
Stop	Toolbar Stop
Review build errors	Problems at the bottom
Review runtime errors	Console, fault dialog, and runtime status

Build and runtime controls remain visible at the top right of the editor: Start / Debug when stopped and Stop while running. Build is available before the first deployment. If the runtime state is unavailable, the controls are disabled with an explanation; check the connection and sign-in status of the Runtime target on the left.

What requires Build

If a change affects pages, logic, data definitions, equipment, or permissions on the target, save it and Build again.

Change	Build required?	Verify
.qp Page, .qpc Component, styles, events, Assets, or i18n	Yes	Rendering, interaction, content paths, and languages
.qg QG program	Yes	Sequence, branches, waits, timeouts, faults, and recovery
Object instance, properties, references, or a custom C# Provider	Yes	ObjectType availability, parameters, and real equipment behavior
Variable or Query	Yes	Initial values, request parameters, and external-system results
App users, roles, home page, or module switches	Yes	Sign-in, permissions, navigation, and enabled capabilities
Motion, Vision, or Safety configuration	Yes	Target hardware, approved versions, interlocks, and failure paths
Git commits, AI conversations, or editor layout	No	These items do not enter the runtime

Build reads only files saved to disk. Unsaved drafts never enter the deployed version. If an open document is dirty, conflicted, or deleted, the editor warns first; continuing still builds the disk content.

Choose a Build Profile

Profile	Use it for	Important detail
Build Debug	Development, fault investigation, and QG source breakpoints	Retains local source-debug information
Build Release	Delivery and performance acceptance	Optimizes Page code and reduces delivery size; does not support QG source breakpoints

The main Build button repeats the last selected Profile. Start can run a deployment that matches the current saved project. Debug requires a Debug version and asks to rebuild a Release deployment. Build and continue uses the Debug Profile for Debug and the last selected Profile for Start.

The native Run menu groups build and lifecycle actions together, but Build/Deploy and Run/Debug remain separate commands. Build Debug and Build Release only build and deploy; the lifecycle starts only after you choose Run or Debug.

Standard workflows

Build and deploy without starting

1. Save every change to be delivered.
2. Verify the Runtime target in the toolbar, especially when production and test targets both exist.
3. Select the required Debug or Release Profile from the Build menu.
4. Select Build. If an unsaved-file warning appears, confirm which disk content will be built.
5. If the App is Running or Debugging, review the downtime impact and confirm Stop and deploy; cancel keeps the current instance running.
6. Wait for success and confirm that Problems has no error that blocks running.

Deployment replaces the version in Stopped. Deployment over a running App requires a confirmed Stop and complete resource cleanup first. The result remains Stopped; explicit Start / Debug creates the runtime instance. Design does not depend on deployment.

Build and continue from Start or Debug

Start and Debug first compare the saved project’s build status with the App and version deployed on the target. A missing deployment, another App, saved file changes, or a deployment that differs from the current build result opens a “Rebuild required” dialog offering Build and continue. Debug also prompts for a Release deployment:

1. Save the changes that should enter the runtime.
2. Verify the action and current Runtime target in the confirmation.
3. Select Build and continue.
4. The editor runs Build and Deploy in sequence, then continues the original Start or Debug only after both succeed.
5. Wait for Running or Debugging before acceptance testing.

Cancel keeps the current state. If Build or Deploy fails, the original Start or Debug does not continue.

App Hub Run also compares the saved project with the target version and asks to Build and run when they differ. If another window replaces the target deployment after the editor’s check, Start/Debug offers the same rebuild confirmation and retries the action only once after success.

Change a running App

1. Change and save the project.
2. Build again for the same Runtime target.
3. Confirm Stop and deploy when prompted; cancel if the current instance must keep running.
4. Start or Debug.
5. Verify normal, boundary, failure, stop, and recovery paths.

Saving files, refreshing the editor, or entering Design does not hot-replace a running instance.

Accept on another machine

The Build flow on this page is the same for local and remote targets, but remote delivery also requires separate checks for the network, secure connection, target access, license, downtime window, and Player. Complete Runtime and field delivery first, then return here for Build and runtime acceptance.

Deliver Vision or Safety changes

A Vision inspection version must pass its validation set and receive responsible human approval before it is activated. Safety changes require engineering interlock tests. Neither change hot-updates a running instance after Save. Stop, Build, Start or Debug, then repeat service-loss, invalid-value, and recovery tests.

Clean

Clean removes only the local Build result for the current project and target so the next Build regenerates it. Clean does not:

• delete or modify project source;
• start another Build automatically;
• delete the App already deployed on a Runtime target;
• clear Saved Variables, Vision data, or other runtime state.

After Clean, select Build again when a new version must be delivered.

Expected results

• Build uses the correct Runtime target and Profile and completes deployment.
• Problems has no error that blocks running.
• The status is Stopped after Build alone.
• Start reaches Running; Debug reaches Debugging.
• Runtime pages, equipment feedback, permissions, and approved configuration match this delivery.
• Stop, fault, and recovery paths have been tested.

Common issues

Build is unavailable

Build is unavailable during Starting, Stopping, or another Build/Deploy operation. Running and Debugging allow Build, but deployment requires Stop confirmation.

Start did not ask for Build, but it runs old behavior

Start checks only saved files. Confirm that your changes are saved and that the correct Runtime target is selected. Unsaved drafts neither trigger an outdated-version prompt nor enter Build. Save and select Start again, or Build explicitly before starting.

The App did not start after Build and continue

Review Problems and deployment errors. The editor continues the original Start or Debug only after both Build and Deploy succeed.

Build asks to stop the running App

Verify the target, site state, and downtime window. Cancel leaves the current instance unchanged. After confirmation, Theseus performs Stop, complete resource cleanup, and image replacement in order.

Build succeeds, but the runtime page still shows old behavior

Confirm that you are viewing the same Runtime target, then Start or Debug again. Close and reopen a page that is still connected to the previous instance when necessary.

Local operation succeeds, but remote delivery fails

Open Runtime and field delivery and check the target address, secure connection, access, license, and equipment conditions. Follow the error returned by the remote operation and real site feedback.

How AI can help

Reference Problems errors and affected files, then limit the scope:

Analyze the current Build failure. Fix only .qp Page, .qpc Component, .qg QG, Object, or C# Provider problems that block the build. Do not change equipment addresses, process sequence, or Safety. Report changed files, diagnostic results, and assumptions that still require human verification.

AI can organize diagnostics and change the project, but it cannot choose a production target, approve replacement, prove equipment actions are safe, or replace site acceptance.

What a person must confirm

• Runtime target, Build Profile, and account permissions are correct.
• Unsaved drafts were not mistaken for delivered changes.
• Equipment addresses, process sequence, role permissions, and Safety were not changed unintentionally.
• Production replacement, downtime, and recovery plans are approved.
• Normal, boundary, failure, and recovery scenarios all pass.