Archived
231 lines
15 KiB
HTML
231 lines
15 KiB
HTML
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<title>The Application Window | HiAPI-C# 2025 </title>
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<meta name="title" content="The Application Window | HiAPI-C# 2025 ">
|
||
|
||
|
||
<link rel="icon" href="../../img/HiAPI.favicon.ico">
|
||
<link rel="stylesheet" href="../../public/docfx.min.css">
|
||
<link rel="stylesheet" href="../../public/main.css">
|
||
<meta name="docfx:navrel" content="../../toc.html">
|
||
<meta name="docfx:tocrel" content="toc.html">
|
||
|
||
<meta name="docfx:rel" content="../../">
|
||
|
||
|
||
|
||
<meta name="loc:inThisArticle" content="In this article">
|
||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||
<meta name="loc:tocFilter" content="Filter by title">
|
||
<meta name="loc:nextArticle" content="Next">
|
||
<meta name="loc:prevArticle" content="Previous">
|
||
<meta name="loc:themeLight" content="Light">
|
||
<meta name="loc:themeDark" content="Dark">
|
||
<meta name="loc:themeAuto" content="Auto">
|
||
<meta name="loc:changeTheme" content="Change theme">
|
||
<meta name="loc:copy" content="Copy">
|
||
<meta name="loc:downloadPdf" content="Download PDF">
|
||
|
||
<script type="module" src="./../../public/docfx.min.js"></script>
|
||
|
||
<script>
|
||
const theme = localStorage.getItem('theme') || 'auto'
|
||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||
</script>
|
||
|
||
</head>
|
||
|
||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
||
<header class="bg-body border-bottom">
|
||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||
<div class="container-xxl flex-nowrap">
|
||
<a class="navbar-brand" href="../../index.html">
|
||
<img id="logo" class="svg" src="../../img/HiAPI.logo.png" alt="">
|
||
|
||
</a>
|
||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||
<i class="bi bi-three-dots"></i>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="navpanel">
|
||
<div id="navbar">
|
||
<form class="search" role="search" id="search">
|
||
<i class="bi bi-search"></i>
|
||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||
</form>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
</header>
|
||
|
||
<main class="container-xxl">
|
||
<div class="toc-offcanvas">
|
||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||
<div class="offcanvas-header">
|
||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||
</div>
|
||
<div class="offcanvas-body">
|
||
<nav class="toc" id="toc"></nav>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="content">
|
||
<div class="actionbar">
|
||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||
<i class="bi bi-list"></i>
|
||
</button>
|
||
|
||
<nav id="breadcrumb"></nav>
|
||
</div>
|
||
|
||
<article data-uid="">
|
||
<h1 id="the-application-window">The Application Window</h1>
|
||
|
||
<p>One frame surrounds every screen: a menu bar across the top, the current page between, and a footer
|
||
along the bottom. The frame is built once and stays mounted for the whole session, so everything
|
||
described here is present on every page. A project change is the one event that reaches into it and
|
||
rebuilds what the middle holds.</p>
|
||
<p>The whole frame at <code>/execution</code>, with the demo project open. Only the column quick-toggles and the
|
||
connection badge, in the middle of the bar, are there because of the page underneath them — the logo,
|
||
the three dropdowns, the page title and <strong>Show Log</strong> sit on the bar whatever page is open, and the
|
||
sign-out button turns on whether a sign-in is asked for rather than on the page. The strip along the
|
||
very bottom is the footer, reading <strong>Ready</strong> because nothing has been reported yet.</p>
|
||
<p><img src="the-app-window-img/app-window.en.png" alt="The Execution page inside the application frame: a menu bar carrying a version badge and the Project, Page and Preference menus, a Control Tree dock and transport buttons down the left, the 3D Rendering Canvas above the Session Messages tabs in the centre, strip charts and step panels on the right, and a one-line footer reading Ready"></p>
|
||
<h2 id="the-menu-bar">The menu bar</h2>
|
||
<p>From the left: the brand logo, a version badge, and the <strong>Project</strong>, <strong>Page</strong> and <strong>Preference</strong>
|
||
dropdowns. The badge is filled from the service's own reply about itself rather than from anything in
|
||
a project, so it carries a version before a project is open. It is drawn only when that reply carried
|
||
one, so a service that cannot answer its own status probe leaves the space empty. The bar is not drawn
|
||
on the sign-in screen at all — the same version appears under the logo on the sign-in card instead.</p>
|
||
<p>The rest of the bar is pushed to the right, and renders in this order:</p>
|
||
<ul>
|
||
<li><strong>The column quick-toggles</strong> — one button per column the current page actually has: four on
|
||
Execution (the dock, the canvas-and-messages column, the Strip Charts column, the Step Info
|
||
column), three on General Setup. Each glyph is a small map of the page with its own column filled,
|
||
and each tooltip names the column it toggles. Tool House lays itself out with draggable splitters
|
||
and gets no buttons here.</li>
|
||
<li><strong>The connection badge</strong> — the Execution page only. See below.</li>
|
||
<li><strong>The current page's title</strong> — the destination's own title, which is where two controls read
|
||
differently from where they land: the Page menu's <strong>Legacy-Controller</strong> entry opens the page titled
|
||
<strong>Controller</strong>, and <strong>Show Log</strong> opens the page titled <strong>Log Viewer</strong>.</li>
|
||
<li><strong>Show Log</strong> — present on every page.</li>
|
||
<li><strong>The sign-out button</strong> — labelled with the signed-in user name, or <strong>Logout</strong> when the service has
|
||
no name for it. It is there only while the service asks for a sign-in.</li>
|
||
</ul>
|
||
<h2 id="the-page-area">The page area</h2>
|
||
<p>Everything between the bars is the current page, and every page reached during a session stays built:
|
||
there is no cap and nothing is excluded. Coming back to one finds its component state, an edit left
|
||
half-finished and an established rendering connection exactly as they were.</p>
|
||
<p>Two things it does not carry over. Nothing restores a scroll position inside a panel: coming back to a
|
||
page finds its panels scrolled to where a fresh mount would put them. And a browser reload is not a
|
||
navigation — it rebuilds the whole application and empties the cache; what survives it is what lives
|
||
outside the page area, namely the address (a <code>?tree=</code> selection in it included) and the layout the
|
||
browser keeps for itself.</p>
|
||
<p><strong>F5 to F8 belong to the Execution page.</strong> They drive its transport — F5 starts or resumes, F6
|
||
pauses, F7 runs one NC line, F8 runs one machining step — and they are bound only while that page is
|
||
the one on screen, so on every other screen F5 is the browser's own reload. A key whose button is not
|
||
available at that moment, or that is pressed with the focus in a text field, is handed back to the
|
||
browser instead. That matters most for F5: while a run is in progress the start button is
|
||
unavailable, so the key reloads the page and takes the session with it.</p>
|
||
<h2 id="what-a-project-change-does">What a project change does</h2>
|
||
<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong> and <strong>Close Project</strong> discard every page the session has built and
|
||
rebuild it against whatever the project is afterwards — nothing at all, after <strong>Close Project</strong>.
|
||
That is what stops a screen showing values from a project that is not open any more, and it is also
|
||
why in-page state that was never saved does not survive one.</p>
|
||
<p>What decides a rebuild is the path changing, not the action. A plain <strong>Save</strong> never rebuilds.
|
||
<strong>Save As</strong> back to the path already open behaves exactly like Save and rebuilds nothing, while
|
||
<strong>Save As</strong> to a different location moves the window onto that path and everything rebuilds. For the
|
||
same reason, picking the already-open project out of the <strong>Load</strong> browser rebuilds nothing either —
|
||
the file is read again on the service, but the screens keep what they were showing. <strong>ReLoad</strong> is the
|
||
entry to use for that, and it is the one that always rebuilds.</p>
|
||
<p>The same rebuild runs once at startup, with nobody having done anything: a browser reaching a service
|
||
that already has a project open receives that path as its first project change and builds on it.</p>
|
||
<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong>, <strong>Save</strong> and <strong>Save As</strong> run one at a time. A second one started while
|
||
the first is still running is refused rather than queued, and the refusal arrives as a warning reading
|
||
<strong>Another project operation is in progress. Please try again.</strong> Nothing is rebuilt and nothing is
|
||
lost. <strong>Close Project</strong> takes no part in that turn-taking and never raises the warning.</p>
|
||
<h2 id="the-footer">The footer</h2>
|
||
<p>A 29-pixel strip holding three regions, each independent of the other two.</p>
|
||
<p><strong>Left — the latest reported line, with the recent ones behind it.</strong> The text is the most recent
|
||
message the application has raised, or <strong>Ready</strong> before there has been one, and its tooltip carries
|
||
the full text with whatever caption came with it. The icon in front decodes the severity: a grey
|
||
information mark for a plain status line, a green tick for a success, an amber triangle for a warning,
|
||
a red mark for a failure. The clock button beside it opens <strong>Recent messages</strong> — newest first, capped
|
||
at a hundred, each row repeating its severity as a coloured strip down the left edge and carrying the
|
||
time it arrived. That list belongs to this browser and this session: <strong>Clear</strong> empties it, a reload
|
||
empties it, and it is written down nowhere.</p>
|
||
<p><strong>Middle — the session strip.</strong> It is drawn only while a run has produced something, and the space is
|
||
simply empty the rest of the time. A glyph leads each line — a locator mark on a cursor tick, the
|
||
message's own severity mark otherwise — and an anchor follows it in a monospaced prefix wherever the
|
||
entry carries one: a cursor line carries <code>Sn</code> and the sentence index it sits on, a message line the
|
||
anchor the message itself supplies. Hovering opens the recent activity behind it; clicking pins that
|
||
list open.</p>
|
||
<p><strong>Right — the background zone.</strong> It appears only while a project file operation is in flight, names
|
||
the operation and the path it is working on, and vanishes when the operation ends.</p>
|
||
<p>Switching the language re-resolves the interface at once and without navigating: the menus, the page
|
||
title in the bar and the browser tab title all change. The two message regions do not follow. Each
|
||
line in the recent list and in the session strip keeps the language it was raised in, so a footer read
|
||
after a language switch is a mixture by design.</p>
|
||
<h2 id="the-connection-badge">The connection badge</h2>
|
||
<p>The badge on the menu bar belongs to the Execution page alone; the other canvases carry their own
|
||
badge inside their panel. It aggregates that page's rendering connection with the service connections
|
||
behind its panels, and reads a green <strong>connected</strong> only while every connection in the set is up —
|
||
orange while any of them is (re)connecting, and red only once none is connecting and one is still
|
||
down.</p>
|
||
<p>The set is not fixed. The rendering connection is always folded in on that page, but a service
|
||
connection joins only while something is actually using it — an open panel, or the frame itself. One
|
||
that nothing is consuming is left out rather than forced to connect. <code>ExecutionStatus</code> has a consumer
|
||
for the whole session and is therefore always in the set; the rest come and go, which is why opening
|
||
and collapsing panels changes what the badge reports. A green badge means every connection in use is
|
||
healthy rather than every connection that exists.</p>
|
||
<p>Only the two problem states carry a tooltip — when everything is connected there is nothing to
|
||
explain and none appears. The tooltip lists one row per connection, <code>Rendering</code>, <code>Shell</code>, <code>NcDiag</code> and
|
||
the rest, and those names are identifiers rather than interface text: in a translated session only the
|
||
state beside each name changes language.</p>
|
||
<p>The buttons that hide those panels' columns are remembered per page. The two tree pages each keep
|
||
their own column choices, while the dock widths and the list of unfolded tree nodes are single
|
||
settings both of them share — widening the dock on Execution widens it on General Setup too.</p>
|
||
<h2 id="see-also">See Also</h2>
|
||
<ul>
|
||
<li><a href="index.html">Basics</a> — the rest of what is true on every screen</li>
|
||
<li><a href="signing-in.html">Signing In</a> — what puts the sign-out button on this bar in the first place</li>
|
||
<li><a href="projects.html">Projects</a> — the Project menu, and what each of its entries does</li>
|
||
<li><a href="finding-your-way.html">Finding Your Way</a> — the Page menu and the screens behind it</li>
|
||
<li><a href="preferences.html">Preferences</a> — the Preference menu, and the settings that are not in it</li>
|
||
<li><a href="messages-and-logs.html">Messages and Logs</a> — the surfaces the footer summarises, and the log behind Show Log</li>
|
||
<li><a href="../run/running-a-simulation.html">Starting and Stepping</a> — the transport those F5–F8 keys drive, and the connection the bar's badge reports on</li>
|
||
<li><a href="../run/watching-the-run.html">Watching the Run</a> — the two columns the quick-toggles show and hide</li>
|
||
</ul>
|
||
|
||
</article>
|
||
|
||
<div class="contribution d-print-none">
|
||
</div>
|
||
|
||
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
||
|
||
</div>
|
||
|
||
<div class="affix">
|
||
<nav id="affix"></nav>
|
||
</div>
|
||
</main>
|
||
|
||
<div class="container-xxl search-results" id="search-results"></div>
|
||
|
||
<footer class="border-top text-secondary">
|
||
<div class="container-xxl">
|
||
<div class="flex-fill">
|
||
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
||
</div>
|
||
</div>
|
||
</footer>
|
||
</body>
|
||
</html>
|