diff --git a/App/EngineMessages/engine-messages.json b/App/EngineMessages/engine-messages.json index 9cf55204..f3e063cb 100644 --- a/App/EngineMessages/engine-messages.json +++ b/App/EngineMessages/engine-messages.json @@ -1,8 +1,8 @@ { "schemaVersion": 1, - "engineVersion": "3.2.28.0", - "filesParsed": 1280, - "siteCount": 365, + "engineVersion": "3.2.29.0", + "filesParsed": 1282, + "siteCount": 366, "sites": [ { "id": "AddTimeDataByFile--Start", @@ -1099,6 +1099,11 @@ "template": "Physics is enabled and {0} steps touched the workpiece, but no touched step produced a physics result. Check that a tool is bound to the spindle, that the spindle rotates through the cuts (M03/M04), and that the workpiece cutting parameter is loaded. Force results are empty for the whole play; if the engagements were not built either (no tool, or spindle never rotating), milling-parameter training will skip every touched step.", "file": "HiMech/MachiningProcs/MachiningSession.cs" }, + { + "id": "Play-RapidCut--Detected", + "template": "Rapid traverse at line {0} (from step {1}) removed {2} mm³ of stock over {3} steps, cutting depth up to {4} mm. On a real machine a rapid move through material breaks the tool or crashes the machine: check the approach clearance, the work offset, the tool length offset and the stock size. Set RapidCutVolumeThreshold_mm3 on the project to ignore grazing contact.", + "file": "HiMech/MachiningProcs/RapidCutMonitor.cs" + }, { "id": "Play-YieldingStress--None", "template": "Tool {0}: physics produced results but the yielding stress ratio could not be evaluated on any touched step (NaN). Check that the cutter is a milling cutter with a flute material, and that its beam geometry has sections outside the tip zone (a section counts only where its height above the tip exceeds its radius). The NcOpt yielding constraint is off for these tools.", diff --git a/App/Hi.WpfPlus.dll b/App/Hi.WpfPlus.dll index 78cf3a9d..58a45028 100644 Binary files a/App/Hi.WpfPlus.dll and b/App/Hi.WpfPlus.dll differ diff --git a/App/HiCbtr.dll b/App/HiCbtr.dll index f3a7acfe..97dc4e4f 100644 Binary files a/App/HiCbtr.dll and b/App/HiCbtr.dll differ diff --git a/App/HiDisp.dll b/App/HiDisp.dll index 89092b55..b8607efa 100644 Binary files a/App/HiDisp.dll and b/App/HiDisp.dll differ diff --git a/App/HiGeom.dll b/App/HiGeom.dll index 10169cf2..69640d9b 100644 Binary files a/App/HiGeom.dll and b/App/HiGeom.dll differ diff --git a/App/HiLicense.dll b/App/HiLicense.dll index 4d9ced6a..cb24cd99 100644 Binary files a/App/HiLicense.dll and b/App/HiLicense.dll differ diff --git a/App/HiMech.dll b/App/HiMech.dll index ba711f45..5fbe35e9 100644 Binary files a/App/HiMech.dll and b/App/HiMech.dll differ diff --git a/App/HiNC-2025-win-desktop.deps.json b/App/HiNC-2025-win-desktop.deps.json index 6f526cf8..1e6deeee 100644 --- a/App/HiNC-2025-win-desktop.deps.json +++ b/App/HiNC-2025-win-desktop.deps.json @@ -11,9 +11,9 @@ "dependencies": { "AvalonEdit": "6.3.0.90", "FontAwesome.Sharp": "6.3.0", - "Hi.WpfPlus": "3.2.24", - "HiNc": "3.2.25", - "HiNc-Resource": "3.2.22", + "Hi.WpfPlus": "3.2.25", + "HiNc": "3.2.26", + "HiNc-Resource": "3.2.23", "Serilog.Extensions.Hosting": "10.0.0", "Serilog.Sinks.Console": "6.1.1", "Serilog.Sinks.File": "7.0.0", @@ -1598,36 +1598,36 @@ } } }, - "Hi.WpfPlus/3.2.24": { + "Hi.WpfPlus/3.2.25": { "dependencies": { - "HiDisp": "3.2.31" + "HiDisp": "3.2.32" }, "runtime": { "lib/net10.0-windows7.0/Hi.WpfPlus.dll": { - "assemblyVersion": "3.2.24.0", - "fileVersion": "3.2.24.0" + "assemblyVersion": "3.2.25.0", + "fileVersion": "3.2.25.0" } } }, - "HiCbtr/3.2.27": { + "HiCbtr/3.2.28": { "dependencies": { - "HiDisp": "3.2.31" + "HiDisp": "3.2.32" }, "runtime": { "lib/net10.0/HiCbtr.dll": { - "assemblyVersion": "3.2.27.0", - "fileVersion": "3.2.27.0" + "assemblyVersion": "3.2.28.0", + "fileVersion": "3.2.28.0" } } }, - "HiDisp/3.2.31": { + "HiDisp/3.2.32": { "dependencies": { - "HiGeom": "3.2.24" + "HiGeom": "3.2.25" }, "runtime": { "lib/net10.0/HiDisp.dll": { - "assemblyVersion": "3.2.31.0", - "fileVersion": "3.2.31.0" + "assemblyVersion": "3.2.32.0", + "fileVersion": "3.2.32.0" } }, "native": { @@ -1645,15 +1645,15 @@ } } }, - "HiGeom/3.2.24": { + "HiGeom/3.2.25": { "dependencies": { "MathNet.Numerics": "5.0.0", "Microsoft.CodeAnalysis.Scripting.Common": "5.9.0" }, "runtime": { "lib/net10.0/HiGeom.dll": { - "assemblyVersion": "3.2.24.0", - "fileVersion": "3.2.24.0" + "assemblyVersion": "3.2.25.0", + "fileVersion": "3.2.25.0" } }, "resources": { @@ -1665,27 +1665,27 @@ } } }, - "HiLicense/3.2.24": { + "HiLicense/3.2.25": { "dependencies": { - "HiGeom": "3.2.24" + "HiGeom": "3.2.25" }, "runtime": { "lib/net10.0/HiLicense.dll": { - "assemblyVersion": "3.2.24.0", - "fileVersion": "3.2.24.0" + "assemblyVersion": "3.2.25.0", + "fileVersion": "3.2.25.0" } } }, - "HiMech/3.2.28": { + "HiMech/3.2.29": { "dependencies": { "CommandLineParser": "2.9.1", - "HiCbtr": "3.2.27", + "HiCbtr": "3.2.28", "Microsoft.CodeAnalysis.CSharp.Scripting": "5.9.0" }, "runtime": { "lib/net10.0/HiMech.dll": { - "assemblyVersion": "3.2.28.0", - "fileVersion": "3.2.28.0" + "assemblyVersion": "3.2.29.0", + "fileVersion": "3.2.29.0" } }, "resources": { @@ -1694,19 +1694,19 @@ } } }, - "HiNc/3.2.25": { + "HiNc/3.2.26": { "dependencies": { "Dapper": "2.1.79", - "HiLicense": "3.2.24", - "HiMech": "3.2.28", - "HiUniNc": "3.2.26", + "HiLicense": "3.2.25", + "HiMech": "3.2.29", + "HiUniNc": "3.2.27", "Microsoft.Data.Sqlite": "10.0.9", "SQLitePCLRaw.bundle_e_sqlite3": "3.0.3" }, "runtime": { "lib/net10.0/HiNc.dll": { - "assemblyVersion": "3.2.25.0", - "fileVersion": "3.2.25.0" + "assemblyVersion": "3.2.26.0", + "fileVersion": "3.2.26.0" } }, "resources": { @@ -1718,22 +1718,22 @@ } } }, - "HiNc-Resource/3.2.22": { + "HiNc-Resource/3.2.23": { "runtime": { "lib/net10.0/HiNc-Resource.dll": { - "assemblyVersion": "3.2.22.0", - "fileVersion": "3.2.22.0" + "assemblyVersion": "3.2.23.0", + "fileVersion": "3.2.23.0" } } }, - "HiUniNc/3.2.26": { + "HiUniNc/3.2.27": { "dependencies": { - "HiMech": "3.2.28" + "HiMech": "3.2.29" }, "runtime": { "lib/net10.0/HiUniNc.dll": { - "assemblyVersion": "3.2.26.0", - "fileVersion": "3.2.26.0" + "assemblyVersion": "3.2.27.0", + "fileVersion": "3.2.27.0" } } }, @@ -2117,68 +2117,68 @@ "path": "fontawesome.sharp/6.3.0", "hashPath": "fontawesome.sharp.6.3.0.nupkg.sha512" }, - "Hi.WpfPlus/3.2.24": { + "Hi.WpfPlus/3.2.25": { "type": "package", "serviceable": true, - "sha512": "sha512-wJGdZWt5bhN4i+1gHxAwijt5ugzZJa1yAiMRpiquS4Y9eaauJPZyTRb9mYFfqH7ketV1z6YI07XiXMKDWFXSxA==", - "path": "hi.wpfplus/3.2.24", - "hashPath": "hi.wpfplus.3.2.24.nupkg.sha512" + "sha512": "sha512-8QBd9q0MGNFjTFuJS7TtWB+Zftpn0RJxIEzVQC+vQ/0FdqQIgLy0GEErsdpEqxO1cMFEbRLNtg7RPQG4gK9iHw==", + "path": "hi.wpfplus/3.2.25", + "hashPath": "hi.wpfplus.3.2.25.nupkg.sha512" }, - "HiCbtr/3.2.27": { + "HiCbtr/3.2.28": { "type": "package", "serviceable": true, - "sha512": "sha512-R670R7hWJvDYWcHVfTb77cN+rrNI/aPcFeNf/I9RI5bn6vw5IBXYaPcHYEVFGIGI8Cc1cO72Asx8vLQZNix6yQ==", - "path": "hicbtr/3.2.27", - "hashPath": "hicbtr.3.2.27.nupkg.sha512" + "sha512": "sha512-el7ZHL9Gq29dui9SK9M5SRLlt8RMNvYVW0AijNunyQODq+F2lqXbE9/i2P8MtvIzDLyTKqdaz4vkpcMpsAdx1g==", + "path": "hicbtr/3.2.28", + "hashPath": "hicbtr.3.2.28.nupkg.sha512" }, - "HiDisp/3.2.31": { + "HiDisp/3.2.32": { "type": "package", "serviceable": true, - "sha512": "sha512-0MDxstmt9aatV8psR5t2dKmOjNsfgp5k1hnC/2i/f/U/nVfCYB3XawOSrF7p7PkUTUg5s6g4LD4RQLqNa6JglA==", - "path": "hidisp/3.2.31", - "hashPath": "hidisp.3.2.31.nupkg.sha512" + "sha512": "sha512-LF2tEwpc+1vXSG+HxYDmOZ1FI5cD8mT2OILlKHeutjzucep3KjhigD09ftdptd98K2TnpBZk/TDKplrCbDxwXQ==", + "path": "hidisp/3.2.32", + "hashPath": "hidisp.3.2.32.nupkg.sha512" }, - "HiGeom/3.2.24": { + "HiGeom/3.2.25": { "type": "package", "serviceable": true, - "sha512": "sha512-XgK3iHUfYJlqeGrc2ZYhAOXcFP5Izuhwm34J3cCID/iN6gYUsHR075TM4yyaoABvde+wkiRGp1/vb5FUavZ4MQ==", - "path": "higeom/3.2.24", - "hashPath": "higeom.3.2.24.nupkg.sha512" + "sha512": "sha512-kDz6FPnxdDf7fIKUy7Ry6WUES17SbbrUZqxjrUko+wp+YMhQZePOT6/x7IqARfoHwMWQa4uyptz/uCqOKWfsvQ==", + "path": "higeom/3.2.25", + "hashPath": "higeom.3.2.25.nupkg.sha512" }, - "HiLicense/3.2.24": { + "HiLicense/3.2.25": { "type": "package", "serviceable": true, - "sha512": "sha512-eYWwIRdk3Nz+tjbdgi5EgoWe1+g57A8RcMktZXQjuxFN8ja5flz6jmy0v4PiK/8oKbKA7HdloU0eCK3vB2FlPA==", - "path": "hilicense/3.2.24", - "hashPath": "hilicense.3.2.24.nupkg.sha512" + "sha512": "sha512-a53li1WcSo6X3raacFoqVTrqM3TvQ/nQYLXBjlD3aFPneIsR8M32TO50f9wDYbeOIMlT90NjEnjrZHxIr+LHhw==", + "path": "hilicense/3.2.25", + "hashPath": "hilicense.3.2.25.nupkg.sha512" }, - "HiMech/3.2.28": { + "HiMech/3.2.29": { "type": "package", "serviceable": true, - "sha512": "sha512-SxUofgDRrDdf44g3pKnWSs6LAQZJK7lDfFu9zKPBsnSx9LNwCzh9xN0d3nTCCj9SI0qVCKd1jcuugKlS7ERaRg==", - "path": "himech/3.2.28", - "hashPath": "himech.3.2.28.nupkg.sha512" + "sha512": "sha512-gyrUo/YozRYciG43oHZLtRaXpmE3zhISgwk7Q8PiW4Bi5QAf/w7KNL3DKj+T18/3brv2owzTtQ7tT5K7myfUDQ==", + "path": "himech/3.2.29", + "hashPath": "himech.3.2.29.nupkg.sha512" }, - "HiNc/3.2.25": { + "HiNc/3.2.26": { "type": "package", "serviceable": true, - "sha512": "sha512-TNDUQ35MFEjIP+SkbkR6WyCsOU4EjoyWFJBmBMAAvjCmOuk2zqAkWF/Z77pcfnRXnfAnfKnbgjkEV0K0l4BW1Q==", - "path": "hinc/3.2.25", - "hashPath": "hinc.3.2.25.nupkg.sha512" + "sha512": "sha512-ClpKih2ipUdtoqcyWUzyk0MLkwMJhJ36uwcBUghHNBvm1ULaHSxEPWOK80/lXVadbchwVfPxL7+LRNs3QbJHuw==", + "path": "hinc/3.2.26", + "hashPath": "hinc.3.2.26.nupkg.sha512" }, - "HiNc-Resource/3.2.22": { + "HiNc-Resource/3.2.23": { "type": "package", "serviceable": true, - "sha512": "sha512-HEWpSyOgRmmT1iXvv3Pzg8uMFoaYW0jmfQjqNrubEUigPJ8FwbAg6Yz1XaN7J5U59EP+jOWt65IN4SaXSNqGJA==", - "path": "hinc-resource/3.2.22", - "hashPath": "hinc-resource.3.2.22.nupkg.sha512" + "sha512": "sha512-sP3Gacc91Gxst3mvC9S5+dcefFkFa/mRZMfashTHA7wmfPRy+xuYJAgUQw0NJs0Oz+qoc0GRE5BZm7IjSp1jvg==", + "path": "hinc-resource/3.2.23", + "hashPath": "hinc-resource.3.2.23.nupkg.sha512" }, - "HiUniNc/3.2.26": { + "HiUniNc/3.2.27": { "type": "package", "serviceable": true, - "sha512": "sha512-dm4RYwFHbAZhkpAxNUNrrraq6gNndM6PWiBO0MBGnUi3nRWeL2GOFiV6k3LAWAIrVY6Ud6dQWwiWMl+q0X/4kw==", - "path": "hiuninc/3.2.26", - "hashPath": "hiuninc.3.2.26.nupkg.sha512" + "sha512": "sha512-JrzVCUM2uu3Reul3VniFDEjPcoFpUvBph0p4yfmKWo2n0ae2emYKF8mixxntT2fzAawC5btqnzCEzDT1/uELeA==", + "path": "hiuninc/3.2.27", + "hashPath": "hiuninc.3.2.27.nupkg.sha512" }, "MathNet.Numerics/5.0.0": { "type": "package", diff --git a/App/HiNC-2025-win-desktop.dll b/App/HiNC-2025-win-desktop.dll index 86236842..c35ad223 100644 Binary files a/App/HiNC-2025-win-desktop.dll and b/App/HiNC-2025-win-desktop.dll differ diff --git a/App/HiNC-2025-win-desktop.pdb b/App/HiNC-2025-win-desktop.pdb index 7805867e..c75f36ad 100644 Binary files a/App/HiNC-2025-win-desktop.pdb and b/App/HiNC-2025-win-desktop.pdb differ diff --git a/App/HiNc-Resource.dll b/App/HiNc-Resource.dll index 8a46fc87..fe60edd1 100644 Binary files a/App/HiNc-Resource.dll and b/App/HiNc-Resource.dll differ diff --git a/App/HiNc.dll b/App/HiNc.dll index a693e465..171a67c3 100644 Binary files a/App/HiNc.dll and b/App/HiNc.dll differ diff --git a/App/HiUniNc.dll b/App/HiUniNc.dll index 59ffb141..1d19dd67 100644 Binary files a/App/HiUniNc.dll and b/App/HiUniNc.dll differ diff --git a/App/StepPresentCatalog/catalog.en.json b/App/StepPresentCatalog/catalog.en.json index fd3f1d05..297eb287 100644 --- a/App/StepPresentCatalog/catalog.en.json +++ b/App/StepPresentCatalog/catalog.en.json @@ -1,6 +1,6 @@ { "schemaVersion": 1, - "engineVersion": "3.2.28.0", + "engineVersion": "3.2.29.0", "recordCount": 98, "records": [ { diff --git a/App/core.dll b/App/core.dll index 465816dc..9046caaa 100644 Binary files a/App/core.dll and b/App/core.dll differ diff --git a/App/en/HiGeom.resources.dll b/App/en/HiGeom.resources.dll index 88573f3a..d32ec38b 100644 Binary files a/App/en/HiGeom.resources.dll and b/App/en/HiGeom.resources.dll differ diff --git a/App/en/HiMech.resources.dll b/App/en/HiMech.resources.dll index 68d58aec..4700b7b5 100644 Binary files a/App/en/HiMech.resources.dll and b/App/en/HiMech.resources.dll differ diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/execution-tool-bar.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/execution-tool-bar.html index 718049c9..23246713 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/execution-tool-bar.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/execution-tool-bar.html @@ -87,7 +87,7 @@

Execution Tool Bar

-

The transport controls for the run. In the web application they sit atop the Execution Page's primary editor panel, shown for the Execution root and every node under it, and this sole instance registers the F5–F8 shortcuts.

+

The transport controls for the run. In the web application they sit in the run header of the Execution Page's Control Tree pane — pinned above the tree, beside the run-state badge, on the Execution page only — and this sole instance registers the F5–F8 shortcuts.

Layout

-

In the web application the status text moved out of the tool bar and onto the Execution tree item, which carries the run-state badge. The two single-advance buttons there share one skip_next icon and are separated by a letter drawn into the button's corner — L for the line button, S for the step button — rather than by colour; the tool-tips carry the key names.

+

In the web application the status text is a run-state badge to the right of the button strip; the two share the Control Tree pane's run header, and when the tree column is narrowed the button strip scrolls while the badge keeps its width, so the run state is the last thing a resize hides. The two single-advance buttons share one skip_next icon and are separated by a letter drawn into the button's corner — L for the line button, S for the step button — rather than by colour; the tool-tips carry the key names.

Behavior

@@ -150,7 +152,7 @@

Neither single-advance button is enabled while the run is Running — stepping is a Ready-or-Paused operation, so a moving run has to be paused before it can be stepped.

-

The F5–F8 handler applies the same predicates before acting, and declines in two more cases: when the event target is an input, a textarea or a contenteditable element, and when the hosting page is deactivated. The second matters because the shell keep-alives the routed pages, so leaving the Execution route deactivates rather than unmounts this component; without the detach, F5 elsewhere in the app would drive the transport instead of reloading the browser. Every declined key falls through to the browser.

+

The F5–F8 handler applies the same predicates before acting, and declines in two more cases: when the event target is an input, a textarea or a contenteditable element, and when the hosting page is deactivated. The second matters because the shell keep-alives the routed pages, so leaving the Execution route deactivates rather than unmounts this component; without the detach, F5 elsewhere in the app would drive the transport instead of reloading the browser. Collapsing the Control Tree row does not detach it: the dock keeps the tree pane mounted through a collapse. Every declined key falls through to the browser.

Tip

Use icons rather than text on the tool-bar buttons. Run One Line and Run One Step share an icon, so they need a second mark to tell them apart — this bar draws an L and an S in the button corner. The default colour is enough for the rest.

@@ -160,6 +162,9 @@

HiNC-2025-webservice (Quasar CLI SPA):

diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/index.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/index.html index 48f3e7c5..57b8ecfe 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/index.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/index.html @@ -87,7 +87,7 @@

Execution Page

-

The Execution page is the run cockpit: the simulation plays here, and every panel on it reads the run. It is the app's landing route — / redirects to /execution — and its Control Tree, the Execution root with Mission and Program beneath it, rides the ?tree= query, so /execution?tree=execution/mission deep-links the Mission editor.

+

The Execution page is the run cockpit: the simulation plays here, and every panel on it reads the run. It is the app's landing route — / redirects to /execution — and its Control Tree — two roots, Mission above Program — rides the ?tree= query, so /execution?tree=execution/mission deep-links the Mission editor.

Note

The app says Execution throughout: the route /execution, the REST endpoints (/api/Execution/*), the status hub (/executionStatusHub) and the stored layout (UserConfig.ExecutionDivConfig). The HiAPI engine keeps its own library vocabulary — PlayerCommand (API) and PacePlayer (API) — which is a different codebase's naming, not an inconsistency here.

@@ -101,16 +101,16 @@

Layout

Four columns, left to right. The two dock dividers are pixel-sized, so dragging one moves only that dock's edge while the flexible middle absorbs the change.

    -
  • Left dock — the Control Tree over the primary editor panel for the selected tree node. The Execution Tool Bar — the transport buttons — sits atop that panel and is shown for the Execution root and every node under it.
    • +
  • Left dock — the Control Tree over the primary editor panel for the selected tree node. The tree pane opens with a run header pinned above its rows: the Execution Tool Bar — the transport buttons — with the live status badge to its right. The editor panel below holds the editor alone.
  • Main — the RenderingCanvas over the Session Message Panel, stacked as collapsible panels with a draggable divider between them. The canvas panel's header adopts the RenderingCanvas Tool Bar and the Execution Extended RenderingCanvas Tool Bar.
  • Strip Charts — the strip-chart group bar over the three Strip Charts: Availability Chart, Surface Roughness Chart and Color Index Time Chart.
  • Step Info — Sentence Syntax as its own region (an NC sentence need not map to any machining step, so it is not a member of the step-based panels), then the Step Info group bar, then Step Properties, CWE (cutter–workpiece engagement) and the four Cycle-Line Charts.

The four columns are toggled from the app menu bar; the panels inside them collapse in place from their own expansion headers. The canvas stays mounted while collapsed so its rendering connection survives, and its engine is paused rather than torn down. The page itself also stays mounted while the user is on another route: the shell wraps the router view in a keep-alive keyed on the project epoch, so navigating away pauses the canvas but keeps the page — and its connection — alive until the loaded project changes.

Control Tree

-

The page hosts an execution-scoped Control Tree: an Execution root with the Mission branch above the Program branch. Selecting a node fills the primary editor pane below the tree, and the Execution Tool Bar is mounted on top of that pane whenever the selected id is execution or starts with execution/ — so the transport stays reachable from every node of this tree.

-

Execution root is the cockpit's home: a short orientation panel, because the controls it would otherwise hold live where they act — the transport on the primary pane's header, the panel switches on each panel's own expansion header, the column switches on the nav bar. The live run state rides the tree itself: the Execution tree item carries a status badge fed by /executionStatusHub.

-

Mission (execution/mission) is the editable command list a run executes — the project's PlayerCommand (API), always a list, with nested lists read as sub-trees. Its ItemType registry supplies the tree checkbox that decides whether a command runs. The branch root is the entry-list editor — Add Command over a drag-reorderable row list with up / down / duplicate / delete — each command entry gets a control bar over that kind's own editor, and each of the kind's remaining setting groups becomes a section child of the command node. Every command type has its own page under Mission.

+

The page hosts an execution-scoped Control Tree with two roots and no wrapper node over them: the Mission branch above the Program branch. Node ids keep the execution/ prefix (execution/mission, execution/program/…) because that first segment is the page-scope key — ?tree= routing and the remembered last selection hang off it — not a parent row; a bare ?tree=execution resolves to execution/mission, and a URL with no ?tree= lands on the remembered selection or, failing that, on Mission. Selecting a node fills the primary editor pane below the tree; that pane holds nothing but the selected node's editor.

+

Run header. The tree pane opens, on this page only, with a row pinned above the tree scroller: the Execution Tool Bar — the page's sole transport, which therefore owns the F5–F8 shortcuts — and, to its right, the status badge fed by /executionStatusHub. It sits inside the pane rather than on the dock's expansion header because that header is shared with General Setup, which renders neither piece. The button strip is the only shrinkable child, so narrowing the tree column scrolls the buttons away while the badge stays in view; the dock keeps the tree row mounted while collapsed, so the transport and its shortcuts survive a collapsed row. The other controls the cockpit needs live where they act — the panel switches on each panel's own expansion header, the column switches on the app menu bar.

+

Mission (execution/mission) is the editable command list a run executes — the project's PlayerCommand (API), always a list, with nested lists read as sub-trees. Its ItemType registry supplies the tree checkbox that decides whether a command runs. Every row-level structural op lives on the tree rows, not in a panel: each command row carries a drag handle and — revealed on hover and on the selected row — move up / move down / duplicate / delete; every list row, the Mission root included, carries an always-visible + (Add Command) that opens the command catalog and inserts the pick right after that list's focused command (the last selected or last added), else at the list's tail. The one panel-side insert is the Program File editor's multi-pick fan-out: each extra pick becomes a new Program File command right after that command in its own list, and the panel reports the insert range to the host, which treats it as a structural op like any row op — the same busy gate, the same carry-over of index-based ids onto the new siblings, the same rebuild scoped to the owning list. Dropping a dragged row on another command row's edge reorders it within its list or relocates it into the target row's list; dropping on a List row's middle band or on the Mission root row appends it into that list. The host runs all five ops through one path — a busy gate that holds tree selection, the checkboxes and further drags read-only while an op is in flight; the open editor's dirty-switch gate, which can refuse the op: a Script Command with unsaved edits asks Save & switch / Discard / Cancel, while an NC Code editor or a List title sends its pending save without asking, and either one answers no when the user cancels or the save does not land — a refused gate drops the op and toasts that the open editor keeps its unsaved edits, which is why a delete that was already confirmed can still leave its row in place; then the API call, a rebuild scoped to the list it rewrote (the nearest list above both, for a move across lists), then the selection. The selection moves only when it already rode on the acted-on row — that row, or a section or nested entry under it: it follows a moved command, lands on the clone of a duplicated one, and after a delete lands on the nearest surviving entry of that list or, once the list is empty, on the owning list row; a selection riding elsewhere stays on its own re-indexed row, and Add Command never moves it at all — only the Add focus moves, onto the new row, so a run of adds chains in order. The root's own panel is informational — what the tree cannot say: a no-project note while no project is loaded, otherwise the command count and, while it is zero, a prompt to click Add Command; the run-order hint closes it either way. A command node's panel is that kind's own editor (a List shows only its optional Title; its entries are its tree children), and each of the kind's remaining setting groups becomes a section child of the command node. Every command type has its own page under Mission.

Program (execution/program) is the read-only inspection twin of Mission: one node per NC source file the session read, its passes and execution marks filled in from run data rather than typed in. Its nodes, its per-pass line and mark views, and the status changes that rebuild it are on Program Branch.

Selection and URL are synced two ways through the tree query argument: the URL's ?tree= is adopted once the tree is built, and every selection change replaces it. A ?tree= id belonging to another page's tree redirects to that page (routeForTreeId), and /mission lands on /execution?tree=execution/mission.

RenderingCanvas Behavior

@@ -129,18 +129,19 @@
  • wwwroot-src/src/pages/ExecutionPage.vue — the routed page at /execution: the four columns, their pixel / ratio splitters, the panel-expansion stacks, and the execution-scoped Control Tree host it provides.
  • wwwroot-src/src/router/routes.ts — the / → execution redirect, the execution route, and the /mission redirect to /execution?tree=execution/mission.
    • -
  • wwwroot-src/src/router/treeRoutes.ts — routeForTreeId, which lands a ?tree= id on the page that owns that branch.
    • -
  • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — the Control Tree state machine: buildExecutionRoot() builds the execution root holding execution/mission above execution/program, syncs ?tree=, and re-reads the Program branch whenever the broadcast execution status changes.
    • -
  • wwwroot-src/src/components/controlTree/ControlTreeDock.vue — the left dock: the Control Tree row over the primary editor row.
    • -
  • wwwroot-src/src/components/controlTree/ControlTreePanel.vue — the tree pane; carries the live execution-status badge on the Execution tree item.
    • -
  • wwwroot-src/src/components/controlTree/PrimarySlavePanel.vue — the primary editor pane for the selected node; mounts the Execution Tool Bar on top whenever the selection is execution or a descendant.
    • -
  • wwwroot-src/src/components/controlTree/ExecutionRootPanel.vue — the editor panel of the Execution root node.
    • +
  • wwwroot-src/src/router/treeRoutes.ts — migrateLegacyTreeId, which folds legacy ids onto the current ones (a bare execution becomes execution/mission), and routeForTreeId, which runs that migration first and then lands a ?tree= id on the page that owns its first segment.
    • +
  • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — the Control Tree state machine: buildExecutionRoots() builds the two roots, execution/mission above execution/program; landingSelection() picks the remembered selection or the first root; the ?tree= sync; the Program branch re-read on every broadcast execution-status change; and the five mission row ops — add, drag move, step, duplicate, delete — through one missionRowOp helper that owns the busy gate, the dirty-switch gate (a refusal drops the op and toasts it), the scoped rebuild and the post-op selection.
    • +
  • wwwroot-src/src/components/controlTree/useMissionTreeDrag.ts — the HTML5 drag-and-drop bookkeeping between Mission rows: the edge / into drop modes and the row indicator classes; the move itself is the host's.
    • +
  • wwwroot-src/src/components/controlTree/ControlTreeDock.vue — the left dock: the Control Tree row over the primary editor row, each kept mounted while collapsed; the tree row's expansion header is the same on both tree pages, so nothing run-specific rides it.
    • +
  • wwwroot-src/src/components/controlTree/ControlTreePanel.vue — the tree pane; on the Execution page it pins the run header — the Execution Tool Bar and the live status badge — above the tree scroller, and renders the Mission rows' drag handle, the hover-revealed row ops and the Add Command + on every list row.
    • +
  • wwwroot-src/src/components/controlTree/AddCommandDialog.vue — the search-first command catalog the + opens, fed by GET /api/Mission/command-catalog; one pick per opening.
    • +
  • wwwroot-src/src/components/controlTree/PrimarySlavePanel.vue — the primary editor pane shared by both tree pages: it mounts the selected node's registry panel, or one of the three inline root panels it carries for General Setup's equipment roots (Machine Tool, Fixture, Workpiece — object management plus a summary), which no Execution node ever selects; here it shows the registry panel alone, and hands that panel's dirty-switch gate to the host.

Mission branch:

  • wwwroot-src/src/components/controlTree/missionItemTypes.ts — the branch's ItemType registry and the per-command enable ticks.
    • -
  • wwwroot-src/src/components/controlTree/MissionRootPanel.vue — the entry-list editor of a list command, serving the branch root and every nested list.
    • -
  • wwwroot-src/src/components/controlTree/MissionCommandSlavePanel.vue — the per-command editor host.
    • +
  • wwwroot-src/src/components/controlTree/MissionRootPanel.vue — the Mission root's informational panel: a no-project note while no project is loaded, otherwise the command count and a “No commands yet” prompt while it is zero, and the run-order hint in every state.
    • +
  • wwwroot-src/src/components/controlTree/MissionCommandSlavePanel.vue — the per-command editor host; a List command shows only its optional Title.
  • wwwroot-src/src/components/controlTree/MissionSectionPanel.vue — one setting section of a command.

Program branch (see the dedicated anatomy page for details):

@@ -150,7 +151,7 @@

Panels and canvas:

  • wwwroot-src/src/components/RenderingCanvas.vue — the browser canvas and its /renderingHub connection.
    • -
  • wwwroot-src/src/components/execution/ExecutionToolBar.vue — the transport controls.
    • +
  • wwwroot-src/src/components/execution/ExecutionToolBar.vue — the transport controls; the page's one instance, mounted in the tree pane's run header, registers F5–F8.
  • wwwroot-src/src/components/execution/ExecutionExtendedToolBar.vue — the view and rendering-flag controls adopted onto the canvas panel's header.
  • wwwroot-src/src/components/execution/SelectedStepInfoPanel.vue — Step Properties.
  • wwwroot-src/src/components/execution/StepVolumePanel.vue — the CWE panel.
    • @@ -173,7 +174,7 @@

    Backends:

    • Execution/ExecutionController.cs — POST /api/Execution/start | pause | resume | run-line | run-step | stop | reset; GET status, status/{connectionId}, project-status, selected-step-info and cl-strip-dots; the canvas actions initialize/{connectionId} (binds the displayee and calls SetViewToHomeView) and fit-view/{connectionId}; and the step-volume/{connectionId} family behind the CWE panel.
      • -
    • Execution/ExecutionStatusHub.cs + Execution/ExecutionStatusService.cs — /executionStatusHub, the run-state broadcast that drives the transport and the tree badge.
      • +
    • Execution/ExecutionStatusHub.cs + Execution/ExecutionStatusService.cs — /executionStatusHub, the run-state broadcast that drives the transport and the run header's badge.
    • Execution/SessionSinkHub.cs + Execution/SessionSinkBroadcastService.cs — one hub per message sink (/shellMessageHub, /ncDiagnosticHub, /stepDiagnosticHub, /ncManipulationDiagnosticHub), so a client subscribes to exactly the sink it wants.
    • Execution/SelectedStepInfoService.cs — the selected-step payload. It has no hub of its own: the “selection changed” push rides /clStripHub.
    • Execution/ClStripController.cs + Execution/ClStripHub.cs + Execution/ClStripBroadcastService.cs — CL-strip range state and the zoom / pan / select / enter broadcasts.
      • @@ -197,10 +198,10 @@

Pages

-

Ordered as the cockpit reads: the two tool bars across the top, the step column and the charts down -the side, the menus and dialogs they open, then the Control-Tree branch the page hosts.

+

Ordered as the cockpit reads: the two tool bars — the transport pinned in the Control Tree pane's run header, the extended controls on the canvas panel's header — then the step column and the charts down +the side, the menus and dialogs they open, then the two Control-Tree branches the page hosts.

    -
  • Execution Tool Bar — The transport controls on the primary panel header, and the status they read
    • +
  • Execution Tool Bar — The transport controls in the Control Tree pane's run header, and the status they read
  • Execution Extended RenderingCanvas Tool Bar — The run-specific canvas controls: the CL strip, fit view and the Scene menu
  • Selected-Step Info Panel — The Step Properties panel in the Step Info column
  • Strip Charts — The whole-program charts in the Strip Charts column
    • diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/ListCommand-panel.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/ListCommand-panel.html index 566843ef..812c31d7 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/ListCommand-panel.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/ListCommand-panel.html @@ -94,11 +94,12 @@ with everything nested under it — the wrapper yields nothing while its flag is own command is always a list, so the Mission branch root is a list, and every nested one is the same shape one level down.

    List is an ordinary catalog kind — category Flow — so a list is added the way any command is, and -adding one grows a sub-tree: the node's children are its own entries, and its panel embeds the same -entry-list editor the branch root uses, scoped to the nested list.

    +adding one grows a sub-tree: the node's children are its own entries, edited on their own Control +Tree rows, and the list's own panel holds only its optional title, beneath the Disabled Caption +while the command is unticked.

    This page covers what a list is, how its title reads, and what moving commands in and out of one -costs. The entry-list editor itself — Add Command, the row actions, the three drag landings — is -documented once, on Mission Root Panel.

    +costs. The Control Tree row affordances every list shares — Add Command, the row buttons, the three +drag landings — are documented once, on Mission Root Panel.

    Key Models

    See Also

      -
    • Mission Root Panel — the entry-list editor this command embeds, documented once
      • +
    • Mission Root Panel — the branch root, and the Control Tree row affordances every list shares, documented once
    • Building a Mission — the task this command serves: grouping a mission and moving entries between groups
    • Mission — the rest of the command panels
    diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcCodeCommand-panel.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcCodeCommand-panel.html index efb7bd3c..f281b06c 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcCodeCommand-panel.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcCodeCommand-panel.html @@ -100,9 +100,13 @@ program name the run log shows, which is why the model defaults it to the comman NC Code, rather than to an empty string. It is also the detail the mission row brackets: the row reads NC Code while the title is empty or still that default, and NC Code [title] once it says something else.

    -

    The panel renders on the command's own node in the Mission branch of the Execution page's Control -Tree, below the move / duplicate / delete control bar. A single-purpose kind like this one embeds -its whole editor on that node rather than growing section child nodes.

    +

    The panel renders on the command's own node under the Mission root of the Execution page's Control +Tree. The editor pane holds nothing but the editor: the command's move up / move down / duplicate / +delete buttons and its drag handle sit on its tree row, and the Add Command + sits on the row of +the list that holds it. A single-purpose kind like this one embeds its whole editor on that node +rather than growing section child nodes. Its tree checkbox only decides whether the run plays the +command; a disabled command is skipped during play — a caption above the title says so — and its +editor stays usable.

    Layout

    • NcCodeCommand Panel @@ -124,7 +128,7 @@ folder is the Script command
    -
  • Stats and Actions Row (web) +
  • Stats and Actions Row
    • Line count and character count, both recomputed as the text changes.
    • Trim Blank Lines Button — trims every line and drops the ones left empty, then saves at once.
      • @@ -137,11 +141,32 @@ CodeMirror with a C# grammar, this one ships a text area.

    Saving

    Typing in either field schedules one save 400 ms after the last keystroke, so a burst of typing -costs one request instead of one per character. Trim Blank Lines and Clear save immediately rather -than through that timer.

    +costs one request instead of one per character. The title and the NC text share that timer, and the +save carries every field edited since the last one. Trim Blank Lines and Clear save immediately +rather than through that timer.

    The write is a single patch endpoint carrying the NC text and the title. Each field is applied only -when the body actually carries it, which is why the client sends the field it changed and a null for -the one it did not.

    +when the body actually carries it, which is why the client sends the fields it edited and a null +for the rest. The endpoint carries no content hash, so nothing on the server refuses a save that +arrives late. After each save the tree relabels the command's node in place rather than rebuilding +the branch, which would remount the editor mid-edit.

    +

    The panel snapshots its command path at mount, and every load and save targets that snapshot +rather than the live selection. The path is an index-based entry path which every structural op +re-points, so the panel hands the Control Tree host a switch gate that runs before the selection +moves off the command and before every mission row op — move, duplicate, delete, drag, Add Command +— wherever in the tree that op acts: the gate first lets a save already on the wire land, then +sends the edit still waiting in the timer while the path is still the command's own. The gate is +there because an op rebuilds the list it rewrites — a drag between two lists rebuilds the nearest +list above both — and that rebuild re-mints the build stamp of every node under the rebuilt list. +Only one command editor is ever mounted, the selected node's, and its mount key carries that stamp, +so the editor remounts when its command sits inside the rebuilt list; the host does not ask whether +it does before running the gate — an op in a list that does not hold this command leaves the +editor mounted, and its staged edit is flushed all the same. A save that fails refuses the op, and +the host drops it with a notice. +Unmount cancels the timer instead of flushing it, so no save from a retired instance can land on +whichever command has slid into its path. Selection and the tick checkboxes are read-only while a +row op is in flight, and equally while a tick's own PUTs are on the wire: the host holds one busy +gate for both, so an enable toggle refuses a selection change and ignores further ticks until its +writes have landed, exactly as a row op does.

    NC text is not validated while it is edited: there is no parse at edit time and no error surface on the panel — the server stores whatever string arrives. Errors surface when the mission plays the text.

    @@ -152,15 +177,35 @@ text.

    • wwwroot-src/src/components/mission/NcCodeCommandPanel.vue — this panel: the Title input, the 18-row monospace text area, the 400 ms debounced saves, the live line and character stats, Trim -Blank Lines, and Clear behind a confirm dialog.
      • +Blank Lines, and Clear behind a confirm dialog; the path snapshot taken at mount, the switch gate +that waits for a save on the wire and then drains the timer, and the unmount that cancels rather +than flushes. +
    • wwwroot-src/src/components/controlTree/MissionCommandSlavePanel.vue — the command node's +slave panel: mounts this editor on the entry path, forwards its switch gate to the host, and +shows the disabled caption above the title.
      • +
    • wwwroot-src/src/components/controlTree/PrimarySlavePanel.vue — mounts the one editor pane, the +selected node's, under a key that carries the node's build stamp; a rebuild that re-mints the +stamp remounts it.
      • +
    • wwwroot-src/src/components/controlTree/ControlTreePanel.vue — the tree rows: the drag handle +and the move / duplicate / delete buttons on the command's row, and the Add Command + on the +row of its list.
      • +
    • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — funnels every selection change +and every mission row op through the active panel's switch gate; holds the one busy gate that +keeps selection and the tick checkboxes read-only while a row op, or a tick's own PUTs, are in +flight; a refused gate drops the op with a notice, and a save relabels the command's node in +place.
    • wwwroot-src/src/components/controlTree/missionItemTypes.ts — maps the nccode kind to this panel, and states the rule it belongs to: a single-purpose kind embeds its whole editor on the -command node.
      • +command node; mints the per-build stamp every command node under a rebuilt list carries.
    • wwwroot-src/src/api/mission.ts — loadNcCode and setNcCode, and the command shape the panel edits (NC code plus title).
    • wwwroot-src/src/i18n/en/mission.ts — the panel's wording: the NC Code label, the character count, Trim Blank Lines, and the line count it shares with the other panels.
      • +
    • wwwroot-src/src/i18n/en/common.ts — the shared strings the panel borrows: the “Title +(optional)” label on the Title Field and the Clear button's label.
    • wwwroot-src/src/i18n/en/dialog.ts — the Clear confirmation's title and message.
      • +
    • wwwroot-src/src/i18n/en/tree.ts — the disabled caption and the notice a refused gate raises on +a row op.
    • Missions/MissionController.cs — the single patch PUT for this command, whose NC-code and title fields are each applied when the body carries them, and the command-snapshot arm that returns both back to the panel.
      • @@ -178,9 +223,9 @@ how this command's NC text persists with the project.

    See Also

      -
    • NcFileCommand Panel — the other Program command: a path to a file instead of text stored in the project
      • +
    • NcFileCommand Panel — the other NC program command among the three kinds the Program catalog category holds (Program File, NC Code, Script): a path to a file instead of text stored in the project
    • Script Command Panel — the rich editor this folder does have, and why this command ships a plain text area instead
      • -
    • Playing a Program — the task these two commands serve
      • +
    • Playing a Program — the task the two NC program commands, Program File and NC Code, serve; the Script command has its own manual page
    • Mission — the rest of the command panels
    diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcFileCommand-panel.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcFileCommand-panel.html index 9c0a6579..465a97d9 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcFileCommand-panel.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/NcFileCommand-panel.html @@ -99,9 +99,13 @@ command: at play time Load Pattern.

    -

    The panel renders on the command's own node in the Mission branch of the Execution page's Control -Tree, below the move / duplicate / delete control bar. This command has no title of its own, so the -row and tree label read Program File [path], the path being the detail the label brackets.

    +

    The panel renders on the command's own node under the Mission root of the Execution page's Control +Tree. The editor pane holds the editor and, while the command's tree checkbox is off, a one-line +disabled hint above it — nothing structural: the command's move up / move down / duplicate / delete +buttons and its drag handle sit on its tree row, and the Add Command + sits on the row of the +list that holds it. This command has no editable Title field — unlike NC Code, Script and List — +so its tree row label is composed from the path alone: Program File [path], the path being the +detail the label brackets.

    Note

    The GUI labels this command “Program File”: it plays NC, CL (CLSF) and CSV files — the runner is @@ -178,11 +182,17 @@ browser to preserve. It is the backstop for a brand extension the NC group does Auto routes to the CL and CSV runners, and everything else falls through to brand NC.

    Multi-Pick Fan-Out

    The dialog is multi-select, and this is the one command editor that grows the mission. The first -picked file lands on this command. Each further pick becomes a new Program File command, added -to the list this command sits in and moved into place directly after it, in pick order — the same -list, so a command inside a nested list fans out inside that nested list. The panel then reports a -structure change, which rebuilds the owning list's branch around the new rows and leaves the -selection on this command.

    +picked file lands on this command. Each further pick becomes a new Program File command, +inserted into the list this command sits in at the index directly after it, in pick order — one +insert per pick, each at the next index, and the same list, so a command inside a nested list fans +out inside that nested list. The panel then reports the insert range — the first new index and +the count — and the command's slave panel scopes it to the owning list and names this command as +the selection. The Control Tree host takes that insert on its structure-changed path, which shares +two things with its own row ops — it holds the busy gate for the rebuild (a change arriving while +another op is in flight is not rebuilt) and carries the index-based ids (the expansion set and the +Add focus) over the new siblings — and not the third: the open panel's dirty gate, which every +row op runs first, is not part of this path. It then rebuilds the owning list's branch around the +new rows and leaves the selection on this command, whose own index is unchanged.

    Where the Program Text Is Edited

    The command stores a path, and the panel does not edit the file. It assigns the path, picks the runner, reports what the server knows about the file, and previews its first 100 lines read-only. @@ -203,14 +213,27 @@ command stores.

    • from; an empty extension list means all files.
  • wwwroot-src/src/components/controlTree/missionItemTypes.ts — maps the ncfile kind to this panel. A kind absent from that map is served by the generic field editor instead.
    • +
  • wwwroot-src/src/components/controlTree/MissionCommandSlavePanel.vue — the command node's +slave panel: mounts this editor on the entry path, and re-scopes the fan-out's structure change +to the owning list, with the insert range and this command as the selection.
    • +
  • wwwroot-src/src/components/controlTree/ControlTreePanel.vue — the tree rows: the drag handle +and the move / duplicate / delete buttons on the command's row, and the Add Command + on the +row of its list.
    • +
  • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — takes the fan-out's insert on +its structure-changed path: the busy gate held for the rebuild, the index-based ids carried over +the new siblings (the two guarantees shared with the row ops; the dirty gate is not one of them), +the rebuild scoped to the owning list, and the selection the payload names.
  • wwwroot-src/src/api/mission.ts — loadNcFile, setNcFilePath, setNcFileNcKind, -getNcFileInfo and previewNcFile, plus the kind union and the file-info shape.
    • +getNcFileInfo and previewNcFile, plus the kind union and the file-info shape; addEntry, +which the fan-out calls with the insert index and which answers the new entry's path.
  • wwwroot-src/src/i18n/en/mission.ts — the panel's wording: the path hint, the Play As hint, the four filter labels, the banner's found and not-found lines, and the preview titles.
  • Missions/MissionController.cs — four endpoints serve this command: a PUT for the path, a PUT for the NC kind, and the two server-side reads behind the banner and the preview (both POSTs, both -resolving a relative path against the project folder). The command-snapshot builder emits the file -path and the NC kind for this kind of command.
    • +resolving a relative path against the project folder). The fan-out's extra picks go through the +list-entry POST, which lands the new entry at the requested insert index — clamped to the list, +the tail when none is given — and answers its index and dotted path. The command-snapshot builder +emits the file path and the NC kind for this kind of command.

HiAPI Engine

    diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/mission-root-panel.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/mission-root-panel.html index 0568c6bc..4f6686fe 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/mission-root-panel.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/mission-root-panel.html @@ -90,17 +90,24 @@

    The Mission branch root of the Execution page's Control Tree: route /execution, Control-Tree path execution/mission, panel MissionRootPanel.vue. /mission resolves to the same place — it redirects onto /execution?tree=execution/mission.

    -

    The panel edits one list of commands: the mission's own command, which is always a -ListCommand. The branch root is therefore a list editor — Add Command, the -entries in run order, and the operations that rewrite the list. Editing a command is not this -panel's job: clicking a row selects that command's tree node, and the command's own editor renders -on that node's panel.

    +

    The node roots one list of commands: the mission's own command, which is always a +ListCommand. Its entries are the node's tree children, in run order, and +the row operations that rewrite the list — Add Command, drag, move up, move down, duplicate, delete — +live on the Control Tree rows and run in the tree host; no panel carries a second copy of them. The +one panel-side insert is the Program File editor's multi-pick: picking several files at once keeps +the first on that command and adds one Program File command per further file right after it, in its +own list, then hands the host the inserted range so the same busy gate and id translation cover the +rebuild. The root's own panel is informational: the command count and the run-order hint. Editing a +command is not this node's job either: selecting a command row opens that command's own editor on +its node's panel.

    Command nodes are addressed by index-derived tree ids and by dotted API paths ("0", "1", nested "0.2"). A command node id extends its parent's, so a root entry is execution/mission/{index} and an entry inside a nested list is execution/mission/{index}/{index}; a command's section children extend it once more, as execution/mission/{index}/{id} keyed on the section. Both forms shift on every structural change — deleting entry 2 slides the next command into path "2" — so each branch -build stamps its nodes afresh and the editor panels remount onto the new paths.

    +build stamps its nodes afresh and the editor panels remount onto the new paths, and the host carries +its own index-based ids — the expansion set, the Add focus and the selection — through every row op +so they follow the rows rather than the slots.

    Key Models

    • Primary: PlayerCommand — the mission's command, @@ -122,17 +129,19 @@ top-down.
      • Mission Root Panel
          -
        • Head Line +
        • No-Project Caption
            -
          • Add Command Button -
              -
            • Opens the Add Command dialog. Disabled while no project is open.
              • +
            • “No project loaded. Open or create a project first.” while nothing is open; the head line, +separator and empty state are withheld with it.
            • +
          • Head Line +
            • Commands Caption
            • Command Count Badge
                -
              • Outlined, and grey rather than primary while the list is empty.
                • +
              • The root list's own entries — the node's command children. Outlined, and grey rather than +primary while the list is empty.
            @@ -140,56 +149,101 @@ top-down.
          • Separator
          • Empty State
              -
            • “No project loaded” while nothing is open; otherwise “No commands yet”, naming Add Command.
              • -
            -
            • -
          • (Each) Command Row -
              -
            • Drag Handle Icon -
                -
              • The whole row is draggable; the handle is the affordance for it.
                • -
              -
              • -
            • Command Label -
                -
              • The command's title as the engine composes it: the kind's localized display name, with a -title the user typed appended as Name [title].
                • -
              -
              • -
            • Move Up Button / Move Down Button -
                -
              • Disabled at the ends of the list.
                • -
              -
              • -
            • Duplicate Button
              • -
            • Delete Button
              • -
            • A disabled command's row is dimmed, and its buttons stay live.
              • -
            • Clicking the row anywhere but on a button selects that command's tree node.
              • -
            -
            • -
          • Drop-Out Zone -
              -
            • Present in a nested list editor only, and shown only while a row is being dragged. It sits -below the rows, so the rows do not shift under the pointer at drag start.
              • +
            • “No commands yet. Click Add Command to create one.” while the list is empty.
          • Run-Order Hint
              -
            • Commands run top-down, and the checkbox on each command's tree item enables or disables it.
              • +
            • Always present. It names the row affordances: commands run top-down in the Control Tree; add +one with + on the Mission or a List row; drag a row to reorder it; a row's own buttons move, +duplicate or delete it; its checkbox enables or disables it.
              • +
            +
            • +
          +
          • +
        • Mission Root Row (Control Tree) +
            +
          • Add Command Button +
              +
            • The +, always visible and pinned to the row's right edge. Opens the Add Command dialog +scoped to the root list. Disabled while no project is open, and while the busy gate is held — +a mission op, or a checkbox toggle's save, in flight.
              • +
            • The row carries no drag handle and no command ops. It is a drop target: anywhere on its height +lands the dragged command in the root list.
              • +
            +
            • +
          +
          • +
        • (Each) Command Row +
            +
          • Enable Checkbox +
              +
            • The tree's tick, and the command's enable switch; a disabled command's label is dimmed.
              • +
            +
            • +
          • Drag Handle Icon +
              +
            • The whole row is draggable; the handle is the affordance for it. Plain and List command rows +carry one; the root row does not.
              • +
            +
            • +
          • Command Label +
              +
            • A real link to the node's ?tree= URL, so the browser's context menu can open it in a new +tab, while a plain click keeps the in-app selection. The text is the command's title as the +engine composes it: the kind's localized display name, with the command's key value appended +in brackets where the kind has one — a List's or Script's typed title, a Program File's file, +a resolution's millimetres, a switch's On / Off.
              • +
            +
            • +
          • Move Up Button / Move Down Button / Duplicate Button / Delete Button +
              +
            • Hidden at rest, revealed on hover and on the selected row, and always shown where there is no +hover to reveal them with (touch). Move Up is disabled on the first entry and Move Down on the +last; all four while the busy gate is held — a mission op, or a checkbox toggle's save, in +flight.
              • +
            +
            • +
          • Add Command Button +
              +
            • On a List row only: the same +, scoped to that list, to the right of the row buttons.
              • +
            +
            • +
          • Drop Indicator +
              +
            • A primary edge line for a before / after landing, a tinted row for a landing into a list; the +dragged row itself dims.
        -

        Enable/disable is not a control on this panel. It is the tree item's checkbox on the command node; a -disabled command is skipped when the mission plays and stays fully editable.

        +

        Enable/disable is not a control on any panel. It is the tree item's checkbox on the command node; a +disabled command is skipped when the mission plays and stays fully editable. A toggle PUTs straight +to the Mission API and flips the node's own state, with no rebuild; on failure the checkbox snaps +back. The toggle holds the same busy gate as the structural ops while its save is on the wire — a +row op sent meanwhile could be applied first server-side and land the flag on whichever command +slid into the ticked path — so until the save lands every row button and + is disabled, no drag +starts, the tree selection is refused, an op that still reaches the host returns silently, and a +further checkbox click snaps back. The gate holds in the other direction too: the checkboxes and +the tree selection are read-only while a mission op is in flight, since a tick would address the +node's pre-op path.

        Add Command

        -

        The button opens a search-first picker. The search box matches a command's display label, its kind -key, or one of its declared aliases — each alias searchable both by its English key and by its word -in the request language. Arrow keys walk the results and Enter takes the highlighted one. Results -are grouped by category, in the catalog's own display order.

        -

        The picked command is appended to the list this editor is scoped to, and the branch rebuilds in -place: the selection stays on the list rather than jumping into the new command's panel.

        +

        The + on the Mission root row, or on any List row, opens a search-first picker. The search box +matches a command's display label, its kind key, or one of its declared aliases — each alias +searchable both by its English key and by its word in the request language. Arrow keys walk the +results and Enter takes the highlighted one. Results are grouped by category, in the catalog's own +display order. One pick per opening: a second click or Enter before the dialog has closed adds +nothing.

        +

        The picked command is inserted right after the focused command when that command is a direct +entry of the list the + is scoped to, and at that list's tail otherwise. The focus is one for the +whole mission, not one per list: the most recently selected command anywhere in the tree (a section +row counts for its owning command), or the last command an Add landed on. So the Mission row's + +never chases a focus inside a nested list — and once a nested command has been selected, the root +row's + appends at the root's tail rather than after whichever root command was selected before +it. The branch rebuilds in place, the new row is revealed and becomes the focus, so a run of adds +lands in order below it, and the selection stays where it was rather than jumping into the new +command's panel.

        The addable set is served by the backend rather than mirrored in a frontend menu. Every engine command carrying [CommandCatalog] is reflected into the catalog, so attributing a new engine command is all it takes for it to appear in the dialog. Thirteen kinds ship:

        @@ -207,42 +261,64 @@ Failure, Physics
        • can override that choice.

Ordering, Duplicating and Deleting

+

Every structural op runs through one path in the tree host: a busy gate that holds every row +affordance, the tree selection and the checkboxes read-only while the op is in flight — the one +gate a checkbox toggle also holds while its save is on the wire, so an op and a tick never +interleave on the server; the open editor's dirty flush — an editor with staged edits (Script, NC +Code, a List's title) saves or resolves them first, waiting for a save already on the wire, and a +refused flush drops the op with a notice rather than silently; the API call; a rebuild scoped to +the list the op rewrote; then the post-op selection. The selection follows the acted-on row only +when it already rode on it — that row, or a node under it — and otherwise stays on its own +re-indexed row, so the editor the user is in is left alone.

Move Up and Move Down move an entry within its own list; they never change which list owns it. Duplicate deep-clones the entry through the same XML round-trip the project file uses — so a nested -list copies with its whole subtree — and the clone lands right after the source. Delete asks for -confirmation in a dialog naming the command.

+list copies with its whole subtree — and the clone lands right after the source; a selection riding +on the source moves onto the clone. Delete asks for confirmation in a dialog naming the command, +before the dirty gate runs, so a cancelled delete forces no save prompt on the open editor; a +selection riding on the deleted row lands on the nearest remaining entry of that list, or on the +list node itself once the list is empty, where Add Command waits.

Dragging a row has three landings:

-

The last two are the same reparent call. The server resolves both lists to object references before -it mutates either, so the index shift the removal causes cannot misroute the insert, and it refuses -to move a list into itself or into one of its own descendants.

+

Which call a landing makes depends on whether the entry changes list, not on where the pointer +sat. A landing that keeps the list — an edge in the entry's own list, or an into-landing on the +list that already holds it (a List row's middle band, or the Mission root row for a root entry), +which sends it to the tail — is the reorder call, the whole new order as one ordered path list; a +landing that changes the list — into a list the entry is not in, or an edge in another list — is +the reparent call. The client refuses to drop a row onto itself or into its own subtree, starts no +drag while the busy gate is held — an op, or a checkbox toggle's save, in flight — and abandons a +drop whose row was re-stamped by a rebuild mid-drag. The server resolves both lists to object +references before it mutates either, so the index shift the removal causes cannot misroute the +insert, and it refuses to move a list into itself or into one of its own descendants. A move across +lists rebuilds from the nearest list above both, and the selection follows the dragged command when +it rode on it.

Nesting

A list entry grows the same structure one level down: its children are its own entries, so nested -lists read as sub-trees at any depth, and the very same panel edits them. The differences are the -scope — the root list, versus the node's own dotted path — and the drop-out zone, which appears only -in a nested editor. A nested list's node adds an optional title above the embedded editor, and that -title is appended to the List name in the row and tree label.

-

Because the mission's own command is always a list, the root and a nested list are one editor at two -scopes. A project file whose stored command is something else loads with that command wrapped into -the root list, so the panel always has a list to edit.

+lists read as sub-trees at any depth, and the very same row affordances act on them. The difference +is the scope — the root list, versus the node's own dotted path: each List row's + inserts into +its own list, and a drop into either lands there. A nested list's panel is the optional title alone, +and that title is appended to the List name in the tree label.

+

Because the mission's own command is always a list, the root and a nested list are one row shape at +two scopes. A project file whose stored command is something else loads with that command wrapped +into the root list, so the branch always has a list to root.

Where a Command Is Edited

-

A command's editor renders on its own tree node, below the control bar carrying the operations that -rewrite the parent list (Up, Down, Duplicate, Delete):

+

A command's editor renders on its own tree node; the row operations that rewrite the parent list stay +on the tree row:

diff --git a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/script-command-panel.html b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/script-command-panel.html index 2ceaadaa..daff084e 100644 --- a/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/script-command-panel.html +++ b/App/wwwroot/HiAPI-docsite/anatomy/execution/mission/script-command-panel.html @@ -93,14 +93,16 @@ the project file, so the script travels with the project. Run evaluates the text against the session shell as the globals object, and when the script returns a sequence of actions that sequence is yielded into the run.

-

The title is what the mission row and the tree node show: the label is composed as Script [title], -falling back to a bare Script while the title is empty. A newly added command starts empty on both -clients — no title, no text.

-

The panel renders on the command's own node in the Mission branch of the Execution page's Control -Tree, below the move / duplicate / delete control bar. A single-purpose kind like this one embeds its -whole editor on that node rather than growing section child nodes. Its tree checkbox only decides -whether the run plays the command; a disabled script is skipped during play and its editor stays -fully usable.

+

The title is what the command's tree row shows: the label is composed as Script [title], falling +back to a bare Script while the title is empty. A newly added command starts empty — no title, no +text.

+

The panel renders on the command's own node under the Mission root of the Execution page's Control +Tree. The editor pane holds nothing but the editor: the command's move up / move down / duplicate / +delete buttons and its drag handle sit on its tree row, and the Add Command + sits on the row of +the list that holds it. A single-purpose kind like this one embeds its whole editor on that node +rather than growing section child nodes. Its tree checkbox only decides whether the run plays the +command; a disabled script is skipped during play — a caption above the title says so — and its +editor stays fully usable.

Layout