Clicking and Dragging Through UI Buttons, or Simulating Swipes Through the Mouse

The actual concept that I am working on is different than how I describe below, but the problem is the same:

I want to create a piano in the UI. Right now my keys are buttons, which are set up in the following way:

   function pianokey:OnActivate()
self.buttonConnection = UiButtonNotificationBus.Connect(self, self.entityId)
self.uiInteractableConnection = UiInteractableNotificationBus.Connect(self, self.entityId)
--Other Code
end
function pianokey:OnDeactivate()
self.buttonConnection:Disconnect()
self.uiInteractableConnection:Disconnect()
end
function pianokey:OnHoverStart()
Debug.Log("Hover Start")
--self:DoPianoStuff()
end
function pianokey:OnHoverEnd()
Debug.Log("Hover End")
end
function pianokey:OnPressed()
Debug.Log("Pressed") --self:DoPianoStuff()
end
function pianokey:OnButtonClick()
Debug.Log("Click")
--self:DoPianoStuff()
end
return pianokey

This works fine (i.e. I can move the mouse and have the events be called), as long as I don’t click and hold within a key/button. Doing so results in only the current key/button receiving events until I release the mouse. To reproduce:

  1. Create a series of buttons
  2. Attach script to each button
  3. Press and hold within any button
  4. Move mouse out of button to another button
  5. Notice that the other button doesn’t call the hover start/end events
  6. Additionally, move back to the original button pressed and notice that it receives hover start/end events
    Is this the intended/expected behavior? If, so, how would I go about changing it? The Lua side of things doesn’t appear to show which button currently has focus (and if that focus can be programmatically changed).

Currently, I am using the Gestures Gem (this will actually be running on a Windows PC with single touch support, so if this should be disabled, let me know).

EDIT: This appears to be the intended behavior. Looking at dev\Gems\LyShine\Code\Source\UiCanvasComponent.cpp around 1720 (HandleHoverInputEvent):


// We don't change the active interactable here. Some interactables may want to still be considered
// pressed if the mouse moves outside their bounds while they are pressed.
// However, the active interactable does influence how hover works, if there is an active
// interactable then that is the only one that can be the hoverInteractable

I suppose now the next step is either to figure out how to change this functionality, or create a component that ceases being the active interactable when the mouse moves outside of its bounds.

It turns out that in my case the solution was to add this single line to DoPianoStuff()

UiInteractableBus.Event.SetIsHandlingEvents(self.entityId, false)

Doing so allowed the canvas to change its active interactable, at the cost of disabling the key. In my case this is fine (this can be a one-off event reset-able by a button in my case). Making this repeatable (and handling multiple taps/slides) is outside of the scope of my current project.

While I have found a solution to my problem, I haven’t actually found a solution to my question (i.e. receiving hover events on other objects while a different interactable is pressed), so I think that I will leave this open for now.

Hi @Roosevelt.Boyland,

Glad to hear that you found a workaround.

As you figured out this is how it is designed to work. While the mouse is being held down after clicking on a button we consider that in a pressed state and we do not send hover events to other elements.

We do have plans to extend the UI input event handling system to be more flexible. In the current release your workaround is one option. One other option would be to use draggables and drop targets to handle dragging from one interactable and getting events as you move over other interactables. That would be more complicated though.