HiNC-Deploy/HiNC-2025-win-desktop-Deploy
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rename XFactory.Regs to XFactory.Generators.

Browse Source
This commit is contained in:
iamboss
2026-05-23 21:23:06 +08:00
parent 8b285cc863
commit 058003f395
155 changed files with 16416 additions and 1261 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/api/Hi.NcParsers.PostLogicSyntaxs.ModalCarrySyntax.html
+24 -2
View File
@@ -6,7 +6,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="title" content="Class ModalCarrySyntax | HiAPI-C# 2025 ">
<meta name="description" content="Per-block modal-section carry. For each key in , if the current block has no section for that key, deep-clone the same section from the immediately previous block (which is itself guaranteed to carry it because every block is processed by this syntax) and set = inside the cloned section. Lets every block stand alone with its full modal context, so downstream readers (cache-file dumps, semantics, UI jumping to a single block) do not need to resolve modal state. This replaces the earlier CacheSyntax design (which sampled every Pace blocks). The legacy CacheSyntax XName is still recognised on load for backward compatibility with previously-saved project files.">
<meta name="description" content="Per-block modal-section carry. For each key in , if the current block has no section for that key, deep-clone the same section from the immediately previous block (which is itself guaranteed to carry it because every block is processed by this syntax) and set = inside the cloned section. Lets every block stand alone with its full modal context, so downstream readers (cache-file dumps, semantics, UI jumping to a single block) do not need to resolve modal state. A JSON section is a candidate for when ALL four criteria hold: Writers concentrated — one or two syntaxes own the section (e.g. / own MotionState; the call/return pair own SubProgramCall-derived state).Readers distributed — multiple downstream consumers each need the value, and none of them should walk back to find it. Single-reader sections do not benefit from blanket carry.Every block must see the section — cache-dump readers landing randomly, single-block UI views, and look-ahead syntaxes all require the section to be present on every block.Carry is unconditional — no frame-gating or other per-block veto. Sections that need conditional carry (e.g. &#39;s frame-aware Vars.Local dict-merge — carry only when MacroFrame matches) belong in the owning syntax&#39;s own carry logic, not here. A section failing any criterion should be carried through its owning syntax&#39;s own logic (single-step node.Previous read, or no carry at all if absence is meaningful — e.g. MacroFrame absent = main frame). This replaces the earlier CacheSyntax design (which sampled every Pace blocks). The legacy CacheSyntax XName is still recognised on load for backward compatibility with previously-saved project files.">
<link rel="icon" href="../img/HiAPI.favicon.ico">
<link rel="stylesheet" href="../public/docfx.min.css">
<link rel="stylesheet" href="../public/main.css">
@@ -106,6 +106,28 @@ inside the cloned section. Lets every block stand alone with its full
modal context, so downstream readers (cache-file dumps, semantics, UI
jumping to a single block) do not need
<a class="xref" href="Hi.Common.Collections.LazyLinkedListNode-1.html#Hi_Common_Collections_LazyLinkedListNode_1_EnumerateBack">EnumerateBack()</a> to resolve modal state.</p>
<p>
A JSON section is a candidate for <a class="xref" href="Hi.NcParsers.PostLogicSyntaxs.ModalCarrySyntax.html#Hi_NcParsers_PostLogicSyntaxs_ModalCarrySyntax_TrackedKeys">TrackedKeys</a> when ALL
four criteria hold:
<ol><li><b>Writers concentrated</b> — one or two syntaxes own the
section (e.g. <a class="xref" href="Hi.NcParsers.LogicSyntaxs.LinearMotionSyntax.html">LinearMotionSyntax</a> /
<a class="xref" href="Hi.NcParsers.LogicSyntaxs.CircularMotionSyntax.html">CircularMotionSyntax</a> own
<code>MotionState</code>; the call/return pair own
<code>SubProgramCall</code>-derived state).</li><li><b>Readers distributed</b> — multiple downstream consumers
each need the value, and none of them should walk back to find it.
Single-reader sections do not benefit from blanket carry.</li><li><b>Every block must see the section</b> — cache-dump readers
landing randomly, single-block UI views, and look-ahead syntaxes
all require the section to be present on every block.</li><li><b>Carry is unconditional</b> — no frame-gating or other
per-block veto. Sections that need conditional carry (e.g.
<a class="xref" href="Hi.NcParsers.EvaluationSyntaxs.Fanuc.FanucLocalVariableReadingSyntax.html">FanucLocalVariableReadingSyntax</a>'s
frame-aware <code>Vars.Local</code> dict-merge — carry only when
<code>MacroFrame</code> matches) belong in the owning syntax's own
carry logic, not here.</li></ol>
A section failing any criterion should be carried through its owning
syntax's own logic (single-step <code>node.Previous</code> read, or no carry
at all if absence is meaningful — e.g. <code>MacroFrame</code> absent = main
frame).
<p>
This replaces the earlier <code>CacheSyntax</code> design (which sampled
every <code>Pace</code> blocks). The legacy <code>CacheSyntax</code> XName is still
@@ -489,7 +511,7 @@ modal value reflects the final, post-compensation state.</p>
</h3>
<div class="markdown level1 summary"><p>XML element name for <a class="xref" href="Hi.Common.XmlUtils.XFactory.html#Hi_Common_XmlUtils_XFactory_Regs">Regs</a> registration.</p>
<div class="markdown level1 summary"><p>XML element name for <a class="xref" href="Hi.Common.XmlUtils.XFactory.html#Hi_Common_XmlUtils_XFactory_Generators">Generators</a> registration.</p>
</div>
<div class="markdown level1 conceptual"></div>