How-To: Show Confirmation Dialogs
Goal: show a Yes/No (or OK/Cancel, or fully custom) modal dialog and branch on the player's answer.
UI.Layer.Modal layer - dialogs are pushed there. You will create the dialog widget in step 1 and register it in step 2.W_CrimsonConfirmationDefault and W_CrimsonConfirmationError (subclasses of UCrimsonConfirmationScreen). If you assigned them as ConfirmationDialogClass / ErrorDialogClass (Quick Start step 6), skip to step 3. Build your own only for custom dialog layout - subclass W_CrimsonConfirmationDialog or UCrimsonConfirmationScreen.1. Build the confirmation screen widget
Create a widget Blueprint with parent Crimson Confirmation Screen (UCrimsonConfirmationScreen). The base class populates it from a descriptor at runtime; you supply the visuals. Four widgets must exist with these exact names (BindWidget):
| Widget name | Type | Purpose |
|---|---|---|
Text_Title | UCommonTextBlock | Receives the descriptor's Header. |
RichText_Description | UCommonRichTextBlock | Receives the descriptor's Body. |
EntryBox_Buttons | UDynamicEntryBox | One button spawned per descriptor action. Set its Entry Widget Class to a UCrimsonButtonBase subclass. |
Border_TapToCloseZone | UCommonBorder | Full-screen backdrop; tapping it (touch) cancels the dialog. |
W_CrimsonConfirmationDefault (/CrimsonUI/UI/Foundation/Dialogs/) - its hierarchy is exactly this table: Border_TapToCloseZone as the backdrop, containing a panel with Text_Title, RichText_Description, and EntryBox_Buttons (whose Entry Widget Class is a UCrimsonButtonBase subclass). W_CrimsonConfirmationError is the same layout styled for errors. Duplicate one as your starting point; the compiler flags any missing BindWidget name.2. Register it in Project Settings
Project Settings -> Crimson -> Crimson UI: set ConfirmationDialogClass (used by confirmations) and ErrorDialogClass (used by ShowError; an OK-only variant of the same Blueprint works) to your widget(s).
3. Show it and branch on the result
Node chain: Show Confirmation Yes No (async) with Title + Message inputs; from its On Result pin, a Switch on ECrimsonMessagingResult with Confirmed / Declined / Cancelled / Killed branches. The other nodes are Show Confirmation Ok Cancel and Show Confirmation Custom (takes a descriptor - in Blueprint, Construct Object from Class a UCrimsonGameDialogDescriptor and fill Header, Body, and ButtonActions; the CreateConfirmation* factories are C++-only helpers). On Result always fires exactly once, even if the dialog cannot be shown (see the result table).
| Result | Meaning |
|---|---|
Confirmed | OK / Yes pressed |
Declined | No pressed |
Cancelled | Cancel pressed, Back action, or tap-to-close |
Killed | Dialog torn down externally before the player answered - treat as 'no decision', not as a No |
Unknown | The dialog could never be shown (dialog class unset, no local player / layout). The callback still fires so the caller doesn't hang. Hidden in the enum, so a Switch on ECrimsonMessagingResult routes it to the default pin - handle it there. |
UI.Layer.Modal; each button routes to the matching branch exactly once.4. Fully custom dialogs
When the standard title/body/buttons layout does not fit (progress dialog, image preview), subclass UCrimsonGameDialog directly (C++) and override SetupDialog(Descriptor, ResultCallback) and KillDialog. Register the class as ConfirmationDialogClass or ErrorDialogClass and the messaging subsystem routes it exactly the same way. Custom button labels and per-button activation delays go through the descriptor's ButtonActions array (FCrimsonConfirmationDialogAction: Result, OptionalDisplayText, ActivationDelay) - a 3-second ActivationDelay on a destructive Confirm gives you the 'hold to confirm' countdown via UCrimsonButtonBase.
See also
- How-To: Buttons & Action Glyphs - the button base the entry box spawns.
- How-To: Push & Pop Screens - the layer mechanics dialogs ride on.