Ignore mouse events on covered buttons

Feature Requests Engine Features
#1

I have some overlapping windows. One window is a shop and another window lets you buy money. The buy money window pops up over the shop window, but the shop buttons eat the inputs, even if you can’t see them. I want the buttons your mouse is hovering over to work and the buttons with something in the way to not work.

Currently the only way to effectively achieve this is to dynamically swap buttons with labels by keeping track of what the mouse is hovering over and what order gui elements are displayed in (hard) to determine whether the button is blocked.

2 Likes
#2

I managed to achieve the effect I wanted by making sure the “buy money” ScreenGui is the last child of PlayerGui. The behavior of overlapping buttons is different depending on whether they are in the same ScreenGui, and for different ScreenGuis, the behavior depends on the order of the ScreenGuis in the hierarchy. It should really depend on the order they appear on the screen, though.

1 Like
#3

I think non-button elements should not block interaction with button elements since non-button elements are sometimes used to stylize buttons. If you need to block input on lower-ZIndex buttons, you should use a button as a background to block the input. Alternatively, we could have a new property to enable this behavior on non-buttons GUIs.

Since you didn’t explain whether you mean that all GUI elements should block lower-ZIndex inputs or if just buttons should, I wanted to bring up this concern.

That being said, buttons won’t even work for this currently. The current behavior seem to be:

  • For buttons in the same ScreenGui
    • Buttons block MouseDown/Up/Click events to lower-ZIndex buttons
    • Buttons do not block MouseEnter/Leave/Moved or MouseWheel events.
  • For buttons in different ScreenGuis
    • Buttons block MouseDown/Up/Click events to lower-ZIndex buttons
    • Buttons block MouseEnter/Leave/Moved or MouseWheel events.

Ideally, if one button is on top of another, it will block all button-related events, regardless of what the hierarchy is.

I was not able to reproduce the “depends on the order of the ScreenGuis in the hierarchy” behavior for ScreenGuis with different DisplayOrders. For ScreenGuis with the same DisplayOrder, both the DisplayOrder and event priority order seems to depend on the order in the hierarchy.

#4

A button with an active property of true will sink mouse events, is something like this what you needed?

#5

If you have one ScreenGui on top of another, then take the bottom one, set Enabled to false and then back to true, it will be put on top. The buttons will act as though they are still on the bottom; the hierarchical order has not changed, but the display order has.

#6

That explains why I got different results. It sounds like maybe the ordering rules for input were not changed when the Enabled property was added for ScreenGuis. That should probably be made into a bug report post if you haven’t yet.