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
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

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	Provider availability, parameters, and real equipment behavior
Variable, Recipe, or Query	Yes	Initial values, recipes, 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	Uses optimized output and does not support QG source breakpoints

The main Build button repeats the last selected Profile. Start can run the deployed version. Use Build Debug before using QG source breakpoints. If Debug triggers Build and continue because the target lacks a current Build, the editor uses the Debug Profile.

Standard workflows

Build and deploy without starting

1. Save every change to be delivered.
2. Confirm that the App is Stopped; if it is running or debugging, Stop first.
3. Verify the Runtime target in the toolbar, especially when production and test targets both exist.
4. Select the required Debug or Release Profile from the Build menu.
5. Select Build. If an unsaved-file warning appears, confirm which disk content will be built.
6. If the target currently contains another App, review the impact before approving replacement.
7. Wait for success and confirm that Problems has no error that blocks running.

The expected outcome is that the new version is deployed to the selected target while the App remains Stopped and no equipment action runs.

Build and continue from Start or Debug

Start and Debug first try to use the current App already deployed on the target. If no App is deployed there or this App has no usable Build there, the editor asks whether to Build and continue:

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.

This confirmation handles “no usable Build on the target.” It does not decide whether saved project files are newer than the delivered version. If you changed files that must be delivered, select Build explicitly.

Change a running App

1. Stop and wait for Stopped.
2. Change and save the project.
3. Build again for the same Runtime target.
4. Start or Debug.
5. Verify normal, boundary, failure, stop, and recovery paths.

Saving files, refreshing the editor, or entering Preview 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 remains 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

The App must be Stopped and no other runtime operation can be active. Stop first or wait for the current operation.

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

The target already has a runnable deployment, so Start does not read the project to compare versions. After saving changes, select Build explicitly and Start again.

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 reports that another App is deployed

Verify the target, site state, and downtime window. Cancel leaves the target unchanged. Theseus stops the old instance and deploys the current App only after confirmation.

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.