Hi,
That’s what we’re trying to handle in UCommonUIActionRouterBase::ProcessInput by sending a new event if the hold “fails”:
`const auto ProcessInputOnActionRouter = [&ProcessHoldInputFunc, &ProcessNormalInputFunc, InputEvent](const UCommonUIActionRouterBase& ActionRouter)
{
EProcessHoldActionResult ProcessHoldResult = ProcessHoldInputFunc(ActionRouter);
if (ProcessHoldResult == EProcessHoldActionResult::Handled)
{
return true;
}
if (ProcessHoldResult == EProcessHoldActionResult::GeneratePress)
{
// A hold action was in progress but quickly aborted, so we want to generate a press action now for any normal bindings that are interested
ProcessNormalInputFunc(ActionRouter, IE_Pressed);
}
// Even if no widget cares about this input, we don’t want to let anything through to the actual game while we’re in menu mode
return ProcessNormalInputFunc(ActionRouter, InputEvent);
};`However, it seems that at this point we’re already handling it in the router, so we’d need a regular binding to handle the fallback event (that is, we can’t rely on the virtual click). What we would *like* to happen here is something like this:
- The face button is pressed, and a hold action begins
- The face button is released early, and the hold action is cancelled. A press action is sent.
- The press action is unhandled (nothing is bound to the bottom face button), so the analog cursor sends it’s click
The problem seems to be the disconnect between the hold action and the generated press action. The hold will tell the analog cursor that it’s handling the event (initially), and the new generated press event doesn’t originate from the cursor. I’m chatting with the team now to see if we can come up with a good long-term fix here, either by sending an event to the cursor when a hold action is cancelled or by having the cursor track button states (it should still receive a key up for that face button, so it could send the corresponding down+up). If you’re looking for a shorter term workaround, you could try adding a flag to CommonAnalogCursor to track the accept button’s state. Then, in FCommonAnalogCursor::HandleKeyUpEvent if the flag hasn’t been set (i.e. you never called FAnalogCursor::HandleKeyDownEvent), you could send it as part of the key up event. Something like this:
// We support binding actions to the virtual accept key, so it's a special flower that gets processed right now const bool bIsVirtualAccept = InKeyEvent.GetKey() == EKeys::Virtual_Accept; if (bIsVirtualAccept && ActionRouter.ProcessInput(InKeyEvent.GetKey(), IE_Released) == ERouteUIInputResult::Handled) { return true; } else if (!bIsVirtualAccept || ShouldVirtualAcceptSimulateMouseButton(InKeyEvent, IE_Released)) { if (!bHandledVirtualAcceptDown) { UCommonInputSubsystem& InputSubsytem = ActionRouter.GetInputSubsystem(); InputSubsytem.SetIsGamepadSimulatedClick(bIsVirtualAccept); bool bReturnValue = FAnalogCursor::HandleKeyDownEvent(SlateApp, InKeyEvent); InputSubsytem.SetIsGamepadSimulatedClick(false); } return FAnalogCursor::HandleKeyUpEvent(SlateApp, InKeyEvent); }I think that should work for you since nothing should be handling that KeyUp event on the accept button, but let me know if you run into any issues. If we’re able to submit a proper fix, I’ll send it your way.
Best,
Cody