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.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. |
Images/CrimsonUI/howto-confirmation-widgets.png2. 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
Images/CrimsonUI/howto-show-confirmation-bp.pngNodes: Show Confirmation Yes No, Show Confirmation Ok Cancel, and Show Confirmation Custom (takes a descriptor - build one with Create Confirmation Yes No Cancel or construct a UCrimsonGameDialogDescriptor and fill Header, Body, and ButtonActions). The single On Result pin delivers an ECrimsonMessagingResult - branch with a Switch on ECrimsonMessagingResult.
| 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 |
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.