It seems this does not bubble from the focused widget up, instead it fires on all widgets on the viewport in a random order. Handling one by setting Binding.bConsumeInput causes no other events to execute, unrelated to bubbling.
Well… I thought this would be THE alternative to overriding all the on key this on mouse that methods and having to read and compare all the keys manually to the input mappings. It’s not actually asking me to do so… is it?
I just need input bubbling starting from the focused widget up the tree, initiated by an input mapping.
Would be nice if the Priority property of the UUserWidget could be configured to respond to change in focus path and its depth position on the widget path. Sadly instead there is a spaghetti web of 30.000+ lines of engine crap instead.
Are you checking if the widget is focused inside OnDoStuff() and returning if it’s not?
Afaik this if you create that binding it will be called on every widget that inherits from that class and the order is “random”.
It’s not really random but since it’s a multi threaded process (or at least that’s what another user told me) you can’t really foresee in which order the components are going to be called (the same happens when you get all the components of an actor and they are listed every time in a different order).
Another thing you could do is saving a reference of the active widget somewhere and calling the function only there, but it’s hard to help you without knowing more about what you are trying to do.
I am checking if it is within the focus path and set the highest priority to the longest path. Strangely an input component with priority 43 and consume set true for a binding does still execute one with priority 42. This seems not to work?
I use BindAction for a specific action on a menu, Menus are nested within a widget tree. The “deepest” widget should receive the highest priority and consume the input bound to the action. In that sense it should work similar to how replies are bubbled or handled by a reply from a method like OnKeyDown, except that I’m not overriding those methods at all.
Figured something out. It’s just one of 100 simple things I barely have time for because they are overcomplicated spaghetti in UE.
Example:
UUserWidget::SetInputActionPriority
- Sets an integer on a widget. Sets the same integer on an input component. Does absolutely nothing.
- The absolute first time anyone for whatever reason someone registers an input component the above integer is read. Afterwards you can forget about updating it without first unregistering the component then re registering it.
Makes sense?
EPIC…
Forgive me but most of the engine code is just frustrating because it was written by either chaotic or inexperienced people. Simple things should just work, we don’t want hyperrealistic graphics when basic functionality does not work. About every single thing in the Slate system which could have been a 1 2 3 step process is a process which takes you half a day to deal with.