HiNC App Anatomy
This section is a transparent, per-component anatomy of the HiNC application family. The forward-looking flagship is HiNC-2025-webservice (Quasar SPA + ASP.NET Core); HiNC-2025-win-desktop (the WPF client) is included only as a legacy reference — it is waiting to be fully obsoleted and is kept here so readers can map old screens onto their web-service successors. Every page dissects one UI component and exposes three layers:
- Layout — the visual / widget tree the user sees.
- Key Model — the backing HiAPI types (MachiningProject, UserService, …).
- Source Code Path — the concrete files (WPF
.xaml+ Quasar.vue+ controller.cs) that implement the component, per application variant.
The sibling General Rules describes conventions shared across the anatomy.
Note
This is not a from-scratch build tutorial. It documents how the shipped HiNC apps are put together, so that:
- End users can understand exactly what each product screen does and which project model each widget edits.
- Developers extending HiAPI-based apps can see a live, production-scale example of every building block mapped to its source.
- AI agents working on the codebase have a single reference for the view ↔ model ↔ source correspondence.
Source Code Repositories
The anatomy covers two codebases. Each page's Source Code Path section lists the implementing file in each repository, but the two are not peers: the web service is the live target, the WPF desktop is the outgoing legacy that the web service replaces.
HiNC-2025-webservice (current flagship)
Quasar CLI SPA (Vue 3 + TypeScript + Pinia + Quasar) served by ASP.NET Core. This is the primary product delivered to end users today and the only target for new feature work.
HiNC-2025-win-desktop (legacy, pending obsoletion)
Native Windows desktop client built on WPF. Slated to be fully obsoleted — listed here only so readers familiar with the desktop UI can locate the equivalent web-service component. Do not start new work against this codebase.
Architecture Patterns
Cross-cutting patterns referenced by many pages:
- DictionaryService and DictionaryHub Pattern — Connection-scoped object indexing for hierarchical components.
- Rendering Canvas on Web Service — WebSocket / SignalR-based 3D canvas architecture.
Reading Guide
Jump straight to the component you want to understand. Most readers will land here via an in-text cross-link; the sections below are a browsable index of the anatomy.
Core Framework
- Initialize HiAPI — Application startup and HiAPI bootstrap.
- Main Panel — The top-level window / layout shell.
- Message Section — Status and notification bar.
Rendering and Visualization
- RenderingCanvas Tool Bar — 3D view-control toolbar.
- Player Panel — Simulation playback and visualization.
Configuration Panels
- Preference Menu — Application settings entry point.
- Graphic-Cache Dropdown — Graphics caching tuning.
Geometry and Mechanism
- Widget Components — Reusable primitives (Vec3dControl, NumericInput, …).
- Geometry Panels — Geometry creation and management.
- Transformers — Coordinate-transformation editors.
- Fixture Page — Fixture configuration.
- Workpiece Page — Workpiece definition.
- ToolHouse Page — Tool library.
Operation
- Controller Page — CNC controller settings.
- Mission Page — Mission (shell-command sequence) editor.
Reading a Page
Each anatomy page is structured so the reader can pivot between the three layers in a single glance:
- Start at Layout to see the widget tree and understand the user-visible structure.
- Drop down to Key Model to learn which backing type each widget edits; click the
<xref:…>links to open the API reference. - Finish at Source Code Path to open the actual file in each repository. “Web Page Application Source Code Path” is the authoritative entry for the current flagship product; the WPF entry is a legacy cross-reference for users migrating off the desktop client.
Tip
If you are starting a new application on top of HiAPI and want a step-by-step build guide instead, see Getting Started. The anatomy is the reference you keep open while you build; the Getting Started page is the tutorial you follow in sequence.
Note
If you are using an AI agent to extend the product, point it at the specific anatomy page whose component you are editing and have it work on the Quasar / ASP.NET Core side. The WPF source paths remain listed so the agent can read the legacy behavior for reference, but new features should land in the web service only — the WPF client is on its way out.