The standalone confirm host — renders a §NS-5 confirm through the window-level confirm overlay (§SAL-2.4). More...
| Header: | #include <StandaloneConfirmController> |
| Inherits: | construct::ui::ConfirmController |
The hub injects an ActivityConfirmController that renders confirmations as MessagePromptActivity overlays on the activity stack. A standalone app has no activity stack, so without a controller every confirm resolves to an empty token — the §NS-5 base "auto-cancel". That is why the window-close (X) save-guard silently did nothing in standalone construct: the guard's Save/Discard/Cancel prompt was auto-cancelled, so the window never closed.
This controller forwards each confirm to toast::confirm(), the window-level confirm host (§NS-8.2), and resolves with the chosen button token. The prompt roles pass straight through, so the window renders the SAME prompt the activity stack would — it simply has no stack to push it onto. toast::confirm() delivers its result on a queued turn, which honours the async guard contract (§NS-5) and stops the guard's continuation from re-entering closeEvent from inside request().
Note: This was a modal QMessageBox when it lived in libconstruct. It is not any more, and neither is the hosted path — §NS-8 replaced both with the in-window notice host. Nothing here blocks the event loop.
Published as the confirm facility on StandaloneActivityContext (§SAL-1); the standalone peer of libwidgets' ActivityConfirmController. The base ConfirmController seam stays in libconstruct (§SA-4 D9) — the one accepted upward header edge (§SA-3).
See also construct::ui::ConfirmController and StandaloneActivityContext.