First off I encurage you to read the tooltips on the functions. They reveal suttle Details in most cases enough to figure out whats going on. (Some apply only under certain conditions!)
You have to understand there is a Priority who recives Input first or even not at all. Thats what the Input Mode is there for. (tooltip again reveals the order)
Next you have to understand that Input can be Consumed and what Bubbeling means. Each Input gets passed to someone (Controller, Character, Widgets etc.) and the one who recives the Input can decide if he wants to Consume it or not. If you Consume the input (or Handle it) that means we are done with the Input nobody else needs to recive it.
If however you decide to not Consume it (leave it Unhandled) you let the Input pass to the next one in the Priority line to recive it. That is called Bubbeling.
If you rember those Important things you should have no trouble in most cases except some Edge cases. (Third Person Click and Hold Mouse from the PlayerController for example can prevent the MouseUp event to fire in the UI)
For most UI related Events keep in mind that the Widget has to have User Focus in most cases. Since the Input System has to know to what UI we want to send the Input. You can different UI respond to the same Key but each one can do something completly different with it. Thats why we need the Focus =)
So, I have been fighting with input modes for game / UI, and Iâm stuck. I used some weird workarounds, but I need a clear solution.
Can I make it so that UI consumes everything mouse related, while player controller still consumes keyboard?
So, dragging and clicking in UI, keyboard in the player controller.
With input mode set to Game and UI:
If I use any custom widget and use âOnMouseButtonDownâ and âOnMouseButtonUpâ the âupâ function doesnât trigger.
Simple mouse click events in player controller also appear to randomly lose input.
How exactly does âcaptureâ work and can I disable it without losing keyboard input?
With input mode set to UI Only:
I can use key events in the player controller (to close the UI for example). In that case âOnKeyDownâ inside the widget works only in some cases. It doesnât work for some widgets and I canât figure out why. That is also a problematic solution since there are many widgets some nested inside each other and I would have to use that function in every single one of them.
Alternatively, is there a way to get player input before player controller gets it and starts applying itâs own weird rules?
Thanks for help.
What I was doing wrong was the event reply in widgets. I was using âmakeâ node (like for structures) and that is empty, didnât notice there where other options.
For the purpose of debugging, since that only fixed part of my problemâŚ
Is there a way to know what consumed an input?
I have this. As simple as it gets. Press event doesnât trigger most of the time. Sometimes it does, not it appears completely random.
So, something has to consume that input. but I have no idea what.
Whats even more weird is that clicking fast works, while clicking slowly, either by holding the button down for longer or by having a longer delay doesnât.
Ok. I found the source of my problem.
I had âshow mouse cursorâ set to true, and Input mode to game only.
It didnât seem like something that could cause problems, but it did.
Thatâs interesting! Your comment fixed my issue. Thanks!
Basically I have a RTS setup where I drag the map by holding down right mouse button.
With the âinput mode to game onlyâ set and cursor shown, the âpressedâ event of the mouse is only caught once and never again.
With hidden cursor, the mouse presses are registered as normal.
I assume in the former case the thereâs some unexpected behavior with the event bubbling getting caught (handled) in a place I wouldnât expect or such.
Iâm still quite new to UE4 but this behavior seems to me as not desirable
Hmm not really. Clicking left mouse button while input is âgame modeâ re-introduces the right clicks not being registered anymore. Perhaps I need to go a completely different route for my âdrag scrollâ implementationâŚ