How-To: Bind CommonUI Actions (UE 5.8+)

Goal: bind UI navigation actions (Escape, Confirm, Back, Tab) to CommonUI widgets directly from Enhanced Input, so glyphs track the player's live binding and you keep no UCommonUIInputData DataTable.

Prerequisites

UE 5.8+, the CommonUI plugin enabled, and a UCommonActivatableWidget subclass of your own that you can edit in C++.

1. Enable Enhanced Input support for CommonUI

In Config/DefaultGame.ini, turn on Enhanced Input support so FBindUIActionArgs accepts a UInputAction* directly. Fill the two action paths with what the Content Browser's Copy Reference gives you for your confirm and back UInputAction assets:

ini

[/Script/CommonInput.CommonInputSettings]
bEnableEnhancedInputSupport=True
EnhancedInputClickAction=<copied reference to your confirm InputAction>
EnhancedInputBackAction=<copied reference to your back InputAction>

Without this flag the binding no-ops

If bEnableEnhancedInputSupport is false, the UInputAction* constructor of FBindUIActionArgs has no effect and your action never fires.

2. Populate UIInputActions and the settings mirror

Open your UCrimsonInputConfig and add one row per UI semantic action to the UI Actions -> UI Input Actions array - each row pairs an InputAction with an InputTag:

`InputTag` on the row	`InputAction` to assign
`InputTag.UI.Escape`	Your Escape / Pause `UInputAction`
`InputTag.UI.Confirm`	Your Accept / Confirm `UInputAction`
`InputTag.UI.Back`	Your Back / Cancel `UInputAction`

Then assign the confirm and back assets a second time in Project Settings -> Crimson -> Crimson Input Settings, under UI Input (Enhanced Input) (UCrimsonInputSettings.UIConfirmAction / UIBackAction), so game code has one authoritative reference that does not depend on holding a config.

Project Settings -> Crimson -> Crimson Input Settings, UI Input (Enhanced Input): UI Confirm Action and UI Back Action assigned.

3. Bind the action in a widget

Resolve the action by tag (from an InputConfig reference the widget holds) and register the binding with FBindUIActionArgs. CommonUI's action router reads the currently-bound key from the player's IMC, so glyphs auto-update on rebind. This step is C++-only - see the callout below.

This binding is C++-only by design

Unreal ships no Blueprint node for FBindUIActionArgs(UInputAction*, ...), and CrimsonInput deliberately does not add one - wrapping CommonUI's binding would pull a UI dependency into an input plugin. Do it once in your own UCommonActivatableWidget base class, as below, and every widget you derive from it inherits the binding. CrimsonInput's role is only to supply the tagged UInputAction assets - and FindUIInputActionForTag is BlueprintCallable, so Blueprint can still look the action up.

cpp

#include "CrimsonInputConfig.h"
#include "Input/CommonUIInputTypes.h" // FBindUIActionArgs

void UMyWidget::NativeOnInitialized()
{
    Super::NativeOnInitialized();
    const FGameplayTag EscapeTag = FGameplayTag::RequestGameplayTag(FName("InputTag.UI.Escape"));
    if (const UInputAction* Escape = InputConfig->FindUIInputActionForTag(EscapeTag, /*bLogNotFound*/ false))
    {
        RegisterUIActionBinding(FBindUIActionArgs(Escape, /*bShouldDisplayInActionBar*/ false,
            FSimpleDelegate::CreateUObject(this, &ThisClass::HandleEscape)));
    }
}

There is no Blueprint node for this binding. Expose a thin BlueprintCallable wrapper (taking the resolved UInputAction*) on your own C++ widget base and call that from Blueprint; FindUIInputActionForTag on your UCrimsonInputConfig gives Blueprint the UInputAction* to pass in.

Verify

The UI action fires from keyboard and gamepad, and rebinding the key updates the on-screen glyph without touching a DataTable.

4. HUD-level Escape

Escape is usually owned by the HUD's root activatable widget rather than by each screen. Give that widget an EditDefaultsOnly TObjectPtr<const UInputAction> EscapeInputAction property, assign your Escape action to it, and bind it exactly as in step 3. Leaving the property null is a useful off switch: bind nothing when it is unset, so a HUD without an Escape action simply does not register one.

Input mode is CommonUI's job, not CrimsonInput's

Which input still reaches gameplay while a menu is open is decided by CommonUI, not by this plugin. Override UCommonActivatableWidget::GetDesiredInputConfig() (or its BP_GetDesiredInputConfig Blueprint event) to return an FUIInputConfig when the widget activates, and use a UCommonInputActionDomainTable for coarser per-layer defaults in UE 5.8. CrimsonInput's job here is only to supply the UInputAction assets and the settings mirror.