Input Mode and TWeakObjectPtr

The articles written on this blog were created with the goal of teaching. Also, the information in the article may be incorrect, so please be careful.

When you open the UI, the mouse works, but there may be a problem where all keyboard shortcuts are blocked. ProjectDT's whiteboard had to continuously receive keyboard input while manipulating the UI.

Choose the Input Mode according to your purpose.

FInputModeGameAndUI InputMode;
InputMode.SetHideCursorDuringCapture(false);
PlayerController->SetInputMode(InputMode);
PlayerController->bShowMouseCursor = true;

FInputModeUIOnlyis suitable when focusing on the UI, but may be too strong for screens that also require key input on the game side. FInputModeGameAndUIkeeps the UI and game input together.

It is also important which widget the focus is on. If the EditableTextBox consumes keystrokes, the shortcut may not be passed on to the PlayerController.

Objects that do not need to be held for a long time are Weak Pointers.

Although the UI Subsystem currently remembers MainWidget and WhiteBoard, it does not need to own the lifetime of those objects.

TWeakObjectPtr<UMainWidget> MainUI;
TWeakObjectPtr<UInvestigateWhiteBoard> ActiveWhiteBoard;

TObjectPtrtracks UObject references and can affect the survival of objects with strong references. TWeakObjectPtrbecomes invalid when the object is destroyed, so check before use.

if (UMainWidget* Widget = MainUI.Get())
{
    Widget->ShowOverlay();
}

Inline Setter of a Weak Pointer that points to a forward declared type may cause a compilation error. It is safer to leave only the declaration in the header and assign it in a CPP that includes the entire definition of the type.

Input mode and pointer type are not trivial syntactic choices. It is a choice to express in code who will receive input and who will own the object lifetime.