This commit is contained in:
2026-09-09 18:06:21 +08:00
parent 161af68fe3
commit 45b9f9ed5d
79 changed files with 1167 additions and 1532 deletions
@@ -87,7 +87,7 @@
<article data-uid="Anatomy-RenderingCanvasToolBar">
<h1 id="renderingcanvas-tool-bar">RenderingCanvas Tool Bar</h1>
<p>The RenderingCanvas Tool Bar is the camera-preset menu that every 3D canvas in the app carries. In the WPF client the control holds a <a class="xref" href="../../api/Hi.Disp.DispEngine.html">DispEngine</a> and drives it directly from each menu click. On the web it holds no engine: it takes a <code>canvas</code> prop and calls that component's exposed <code>setView(name)</code>, which invokes the <code>SetView</code> hub method, and the hub is what drives the per-connection <a class="xref" href="../../api/Hi.Disp.DispEngine.html">DispEngine</a>.</p>
<p>The RenderingCanvas Tool Bar is the camera-preset menu that every 3D canvas in the app carries. It holds no engine of its own: it takes a <code>canvas</code> prop and calls that component's exposed <code>setView(name)</code>, which invokes the <code>SetView</code> hub method, and the hub is what drives the per-connection <a class="xref" href="../../api/Hi.Disp.DispEngine.html">DispEngine</a>.</p>
<h2 id="view-menu">View Menu</h2>
<p>The bar is a single <code>View ▾</code> menu. Its seven entries, in shipped order, are Isometric, Front, Back, Right, Left, Top and Bottom. The engine also understands a <code>home</code> view and <code>RenderingCanvas.vue</code> exposes <code>setViewToHomeView</code>, but this menu does not offer it.</p>
<table>
@@ -129,9 +129,9 @@
</tbody>
</table>
<h3 id="back-view-implementation">Back View Implementation</h3>
<p>Back / Left / Bottom views are composed by first calling the corresponding forward-view method (<code>SetViewToFrontView</code> / <code>SetViewToRightView</code> / <code>SetViewToTopView</code>) and then invoking <a class="xref" href="../../api/Hi.Disp.DispEngine.html#Hi_Disp_DispEngine_TurnBackView">TurnBackView()</a> to flip the camera about the view plane. Both clients compose them the same way — the web in the hub's <code>SetView</code> switch, WPF in the tool bar's click handlers.</p>
<p>Back / Left / Bottom views are composed by first calling the corresponding forward-view method (<code>SetViewToFrontView</code> / <code>SetViewToRightView</code> / <code>SetViewToTopView</code>) and then invoking <a class="xref" href="../../api/Hi.Disp.DispEngine.html#Hi_Disp_DispEngine_TurnBackView">TurnBackView()</a> to flip the camera about the view plane, composed in the hub's <code>SetView</code> switch.</p>
<h3 id="canvas-binding">Canvas Binding</h3>
<p>On the web the tool bar declares exactly one prop, a nullable <code>canvas</code>, typed structurally as an object exposing <code>setView(v: string): Promise&lt;void&gt;</code> rather than as the <code>RenderingCanvas</code> component type. Every entry calls it optionally, so a tool bar with no canvas bound still opens and each entry is a no-op. The preset names travel to the hub untranslated; only the row labels are localized, from the <code>widgets.canvas.*</code> keys.</p>
<p>The tool bar declares exactly one prop, a nullable <code>canvas</code>, typed structurally as an object exposing <code>setView(v: string): Promise&lt;void&gt;</code> rather than as the <code>RenderingCanvas</code> component type. Every entry calls it optionally, so a tool bar with no canvas bound still opens and each entry is a no-op. The preset names travel to the hub untranslated; only the row labels are localized, from the <code>widgets.canvas.*</code> keys.</p>
<h2 id="scene-menu">Scene Menu</h2>
<p>Pages that sit next to a <code>RenderingCanvas</code> surface a per-page <code>Scene ▾</code> menu button — the <code>DisplayOptionsMenu</code> component, labelled from <code>widgets.canvas.scene</code> because no caller overrides the label. It chooses what the 3D scene draws (solids, coordinates, display aids), as distinct from the camera-oriented <code>View ▾</code> menu beside it. The layout (header + checkboxes + radio rows) is shared across four callers — the Execution page's extended tool bar, the General Setup equipment panel, the Tool House setup panel and the STL preview pane — so it is implemented once as a generic, schema-driven component.</p>
<h3 id="schema">Schema</h3>
@@ -154,10 +154,6 @@
</li>
<li>Backends — one per caller, each a different surface: <code>ExecutionExtendedToolBar.vue</code> reaches <code>/api/rendering-flags</code> (<code>Common/RenderingFlagsController.cs</code>), which flips bits in <code>ExecutionDisplayee.RenderingFlagBitArray</code>; <code>EquipmentSetupPanel.vue</code> reaches <code>/api/mech/equipment-setup-display/*</code> (<code>Mech/EquipmentSetupDisplayController.cs</code>); <code>ToolHouseSetupPanel.vue</code> reaches <code>/api/mech/tool-house-display/*</code> (<code>Mech/ToolHouseDisplayController.cs</code>); <code>StlPreviewPane.vue</code> reaches <code>/api/stl-preview/set-coordinate/*</code> (<code>Disp/StlPreviewController.cs</code>). Those last three route each POST by the caller's <code>renderingConnectionId</code>, so the toggle lands on that canvas's own engine; the rendering-flags surface carries no connection id and acts on the project-wide <code>ExecutionDisplayee</code> instead. <code>DisplayOptionsMenu.vue</code> is UI-only; it does no REST work itself — the caller owns the <code>onUpdate</code> handlers, so optimistic update and error reversion stay page-local.</li>
</ul>
<h3 id="wpf">WPF</h3>
<ul>
<li><code>Play/RenderingFlagSubmenu.xaml</code> — the shared flag submenu, wrapped per surface by <code>Numerical/Controller/ControllerExtendedRenderingCanvasToolBar.xaml</code> and <code>Play/PlayerExtendedRenderingCanvasToolBar.xaml</code>. Behaviour parity with the web <code>Scene ▾</code> menu; no schema-driven composition.</li>
</ul>
<h2 id="source-code-path">Source Code Path</h2>
<p>See <a class="xref" href="../index.html">HiNC App Anatomy</a> for git repository links.</p>
<p>HiNC-2025-webservice (Quasar CLI SPA):</p>