Table of Contents

HiNC App Anatomy

Anatomy is the view ↔ model ↔ source reference for the shipped HiNC applications: one page per component, each naming the widget tree the user sees, the HiAPI types behind it, and the files that implement it. It documents how the shipped apps are put together — it is not a build tutorial, and for that see Getting Started.

The section is grouped by the surface that owns a page: a folder per live route that hosts a Control-Tree branch or several pages, a single page where a route needs only one, and — where the shipped surface owns nothing, as with a reusable control or a cross-screen rule — the source directory the components actually live in.

Important

Anatomy makes no claim that Control-Tree ids are stable across versions, and no page may state one. treeRoutes.ts guarantees something narrower: an old id keeps resolving, because each regroup adds a migration hop. The ids themselves have moved repeatedly.

Finding the Page From the App

What you are looking at Where its anatomy is
The window frame, its menu bar and its message bars App Shell
/execution, and ?tree=execution/… on it Execution Page — its Mission branch is under Mission
/general-setup, and ?tree=equipment/… on it General Setup Page — its Controller branch is under Controller
/machine-tool Machine Tool — the route is a read-only preview of the same branch
/tool-house/:toolId?/:tab?/:subtab?, and ?tree=toolhouse/… Tool House Page
/controller/:tab? Legacy Controller
/util/file-explorer, /util/mech-builder Utility Pages
/login, /preference/log Platform — the two routes that document the platform rather than a machining step
A geometry editor embedded in any of the above Geometry Panels
A control that appears on more than one screen Widgets
A rule that holds across screens rather than on one Conventions
Machinery under every screen — the Control-Tree engine, the ?tree= id surface, the locale bundles, the host process Platform
A directory in one of the source trees, rather than a screen By Source Directory

Sections

  • Conventions — The rules and shared contracts every page assumes: messaging, file paths, numeric values, the hub patterns, the canvas transport
  • Platform — The machinery every route sits on and no user can point at: the Control-Tree engine, the id and route surface, session state, the locale bundles, the login gate, the log viewer and the host process
  • App Shell — The frame every route renders inside: the Main Panel, its two message bars, and the Preference menu
  • Widgets — The reusable controls pages embed rather than own, most-embedded first
  • Geometry Panels — The primitive solids, the operators that combine and mesh them, and the switchboards that host both
  • Execution Page — The run cockpit: its tool bars, the step column, the charts, and the Mission branch it hosts
  • General Setup Page — The equipment Control Tree: the machine, the spindle envelope, the scene, the fixture, the workpiece and the controller branch
  • Tool House Page — The tool library and the per-tool editor tabs, cutter and holder
  • Legacy Controller — The superseded HardNcEnv controller surface and its REST implementation
  • Legacy Controller Settings — The HardNcEnv model that surface edits: the three settings it owns alone, what it shares with the Controller branch, and the engine files behind both
  • Utility Pages — The two /util/ routes: the File Explorer and the Mechanism Builder
  • By Source Directory — The same knowledge keyed on the source tree instead of the screen: one directory index per half of the flagship

The Two Codebases

A page's Source Code Path section lists the files that implement it in the flagship web service. The desktop client's counterparts are not listed at all: it takes no new feature work, and a hand-maintained map of its files went stale faster than anyone read it. The two codebases are not peers.

HiNC-2025-webservice is the flagship — a Quasar SPA (Vue 3 + TypeScript + Pinia) served by ASP.NET Core, and the only target for new feature work. Repository: HiNC-2025-webservice.git

HiNC-2025-win-desktop is the outgoing WPF client, kept here only so a reader familiar with the desktop UI can find the equivalent web-service component. Do not start new work against it. Repository: HiNC-2025-win-desktop.git

Tip

The host process, its configuration and the address it listens on are documented in Program and Hosting.

Writing a Page Here

  1. Name the surface it documents in prose — the route, and where the component lives in a Control Tree, its ?tree= id. Make no claim that the id is stable.
  2. Layout — the widget tree as the user meets it, nested as the UI nests.
  3. Key Model — the backing HiAPI types, as <xref:> so the API reference is one click away.
  4. Source Code Path — the implementing files in the web service. Backtick every path, with its extension: tools/check-source-paths.ps1 resolves a full path against the source tree and a bare file name by its base name, and refuses an entry carrying no backticks at all. Do not add desktop-client files.
  5. ## See Also — mandatory, and audited for reciprocity. An entry is not landed until the target links back. Anatomy is authoritative on component and source facts: when Manual and Anatomy disagree, Anatomy is corrected first and Manual follows.

See Also

  • Anatomy by Source Directory — the inverse index: enter by the directory a change landed in rather than by the screen it shows up on
  • Manual — the same shipped screens as an operating procedure rather than a component breakdown