Set/bind on mouse events for elements inside the Widget

In a Widget you have the option to override the functions On Mouse like On Mouse Enter/Leave which are useful if you are doing something with that Widget as a whole, but it is way too general if you want to do something with elements inside it separately that you need the same On Mouse X function.

The problem that I have is that I don’t see a way to bind/call a function to do the same thing like you can for the Widget, but for each element in particularly. I only see two ways to achieve this:

  1. To create On Tick event, and inside it to check with a bool branch Has Mouse Captured for each element that you are interested in doing something when the mouse is over that element for example, but this is a bit tedious if you have quite a few elements you want to do this for, and also it doesn’t give the same control like with the overrides you have for a widget;
  2. To create a new widget with each element you want to do something On Mouse events, and add/create that Widget inside the “Main widget”. This will give you the same control as you have with a widget as the elements themself are now widgets and not simple overlays, or images, or… This will also require more work then just having an option for an Overlay for example to bind/set on mouse X event.

That being said, did I missed something and what I want can be achieved simply by calling a bind/function for each element, or I really need to do it one of the two ways I mentioned above?

1 Like

You did not miss anything. And #2 is the way to go, #2 is the only feasible way to go in order to achieve an interface that is maintainable, modular, flexible and scalable.

Once you start wrapping native element in user widgets, there’s no looking back.

There’s also no looking back once you start using Named Slots and then finally figure out how the heck widget inheritance works.

And even all the above eventually becomes underwhelming. Unlike Slate, UMG cannot easily produce certain behaviours. Here’s a fantastic post addressesing lackluster UMG tunnelling / bubbling handling:


My advice is: absolutely do, and wholeheartedly, too, embrace User Widgets. :people_hugging:

2 Likes

Too bad. I was hoping this time I missed something. I come from a Java/JavaFX background and there each element from GUI have at one point in their parent/child hierarchy the same parent that contains all the mouse events as well as key press/released/typed events, and other more general events, and so you have access to them on each element and not just that scene/widget equivalent in Unreal Engine. Which in some situations are extremely useful.

Yeah, that was the way I was going to go with, because even if you have a button with other elements in a widget created inside another widget, and you want that button to do something different for each instance of that child widget, you can simply get “child widget” → get button → Bind Event To on X.

I had a few similar situation and I applied what I said above, but the difference is that in my case I only had 1 layer (main widget, and a child widget inside it with the button), and I could easily reach the button, and not had to call X gets to reach it.

A bit easier for me if I had a situation where I would have a widget inside another, inside another… which in the end has the button I would need to do something different each time, is that for each child widget I would create a function “Get Button” which would return the “Get Button” function from it’s child, until I reach the bottom child, where “Get Button” function would return the button itself. And so inside the main widget I could simply use “child widget” → Get Button → Bind Event to On Clicked.

A visual representation simplified:

Bottom widget that has the button itself:
image

1 layer/widget higher:
image
image

2 layers/widgets higher:
image
image

… how many layers/widgets higher you would have…

Top layer/widget:
image
image

Like he said it isn’t an elegant solution, but at least it is only tedious and not hard to implement. I’m the only one working on my project/game, and so, even if some things might be tedious, I will give in and make something like the hierarchy I said above, only to keep it going, and not get stuck in trying to get a better/elegant solution, which in the end, giving in, is kinda better because I’ll get on with the project, but on the other hand, maybe if I spend more time to find a better solution, it would save me time in the future?! Pros and cons situation.

1 Like