Table of Contents

Holder Panel

This section describes the user interface and behavior for managing different types of tool holders in the application. Tool holders are crucial components in defining a complete tool assembly.

Note

While tool holders are essential components in real-world machining operations, some users may choose not to define them in simulation environments for convenience, particularly when collision detection is not a primary concern. The system allows for this flexibility, though it's recommended to include holders for accurate representation and comprehensive collision analysis.

The primary models involved implement IHolder, and the Holder node offers both of its implementations:

Each holder type has its own user interface elements for defining its geometry and properties.

It is the panel of the Holder node, one of the roots of the picked tool's Control Tree on the Tool House Page: the node toolhouse/tool-{toolId}/holder, reached at /tool-house/:toolId/holder. Selecting the node shows this panel in the editor column.

Layout

Web Layout

  • Holder Node Panel
    • Title Label
    • Holder Type Selector — None / Cylindroid Holder / Freeform Holder
    • Identity Fields, rendered while the type is Cylindroid or Freeform
      • Name TextField (editable)
      • Abstract Note TextField (readonly, derived by the model)
      • Note TextField (editable)
      • Sections Hint Caption — names the sections below for the current type
    • No-Holder Hint, rendered while the type is None: toolhouse.holder.noHolderHint, inviting the reader to pick Cylindroid Holder or Freeform Holder

The three identity fields belong to whichever holder the tool carries. They sit on this panel under the Metadata-on-container convention — a container's own General fields are edited on the container's panel instead of in a General child — and they commit through the per-type holder controller's SetName and SetNote (CylindroidHolderController or FreeformHolderController), not through ToolHouseController. No holder leaves the panel without them.

The type also decides what grows below the node. A Cylindroid holder grows two child nodes, Geometry and Resolution — the nodes whose role paths end in .../holder/geometry and .../holder/resolution; see Cylindroid Holder Panel. A Freeform holder grows four — Geometry, Geom To Spindle, Geom To Cutter and Resolution; see Freeform Holder Panel. Selecting one of them shows that node's own panel in the editor column in place of this one. None grows no children, so the Holder node is a leaf and the hint is the whole surface. A URL naming a node the holder does not grow — /tool-house/:toolId/holder/geom-to-spindle on a Cylindroid holder, or any node below a holder of type None — lands on the Holder node, the deepest node the tool grows along that path, and the URL is rewritten to it.

This panel carries no object management of its own. Object management for the tool library sits at the head of the page's tool list, on the Tool House Root Panel, where the Object Management Menu Button is bound to the whole tool house — file extension .MachiningToolHouse — rather than to a per-holder file.

Feature

Committing a type is one server call plus a cache clear. SetHolderType maps the selector value onto the holder classes: none clears the tool's holder, while cylindroid and freeform each assign a new holder only when the tool does not already carry one of that class — so re-picking the type a tool already has keeps the holder it has, and the edits on it, rather than replacing it. The panel passes its session key, so the server re-indexes the resulting holder under that session's holder key, {sessionKey}-Holder, and removes that entry for None, so the session key keeps pointing at the tool's current holder. The response carries the holder's class name and its abstract note.

The panel then calls ClearToolCache, which clears the tool's cached solids and, when the holder implements IClearCache, the holder's own cache as well, so the tool canvas redraws against the new holder. It re-reads the three identity fields through the per-type Get, and finally emits a structure change for its own node: the Control Tree rebuilds the Holder branch in place and keeps the Holder node selected, which is how the nodes below appear, disappear or change with the type.

GetHolder reports the same pair — class name and abstract note — and is what the panel reads on mount to seed the selector; an unknown tool id answers Not Found. The panel then reads the per-type controller's Get (CylindroidHolderController or FreeformHolderController) to fill the three identity fields. It passes the session key, so that same call also re-indexes this holder's members under the session's keys for the nodes below — {sessionKey}-HolderCylindroid for a Cylindroid holder; {sessionKey}-HolderGeom, {sessionKey}-HolderGeomToSpindle and {sessionKey}-HolderGeomToCutter for a Freeform holder.

Source Code Path

See HiNC App Anatomy for git repository links.

HiNC-2025-webservice (Quasar CLI SPA):

  • wwwroot-src/src/components/controlTree/toolhouse/ToolHolderPanel.vue — the Holder node's panel: the None / Cylindroid / Freeform selector, the holder's Name / readonly Abstract Note / Note (committed through the per-type controller) and the no-holder hint. Commits a type change through setHolderType followed by clearToolCache.
  • wwwroot-src/src/components/controlTree/toolHouseItemTypes.ts — registers this panel as the ToolHolder item type; its holder child builder grows Geometry and Resolution for a CylindroidHolder, Geometry / Geom To Spindle / Geom To Cutter / Resolution for a FreeformHolder, and nothing for None.
  • wwwroot-src/src/components/controlTree/toolhouse/HolderSectionPanel.vue — the panel behind the Cylindroid holder's two nodes and both holders' Resolution node, dispatching on the last segment of the node's role path and on the holder type.
  • wwwroot-src/src/components/controlTree/useControlTreeHost.ts — the Control-Tree host in its toolhouse scope: rebuilds the Holder branch on this panel's structure change, and clamps a URL naming a node the holder does not grow to the deepest node it does.
  • wwwroot-src/src/components/controlTree/toolhouse/ToolHouseRootPanel.vue — the head of the page's tool list, which carries the Object Management Menu Button for the whole tool house.
  • wwwroot-src/src/api/toolHouse.ts — getHolder, setHolderType and clearToolCache. setHolderType sends the selector's value (None / Cylindroid / Freeform); getHolder answers with the HolderType union (None / CylindroidHolder / FreeformHolder), which the panel maps back onto the selector.
  • wwwroot-src/src/api/cylindroidHolder.ts / wwwroot-src/src/api/freeformHolder.ts — get…Holder, set…HolderName and set…HolderNote for each holder type, behind the three identity fields.
  • wwwroot-src/src/i18n/en/toolhouse.ts — the toolhouse.holder.* strings this panel renders: holderType, abstractNote, sectionsHint, freeformSectionsHint, noHolderHint, cylindroidHolder, freeformHolder.
  • Mech/ToolHouseController.cs — POST SetHolderType, GET GetHolder and POST ClearToolCache, the three endpoints behind the selector. Per-holder-type editing lives in the dedicated holder controllers. SetHolderType and ClearToolCache answer 409 ToolEditRefusedWhileRunning while the pace player is locked — a run in progress or paused — as does every edit on the two holder controllers, the holder hanging on the tool the run mounted; GetHolder and the per-type Get do not.

See Also