Why are there no options other than "Handled" and "Unhandled" for widget mouse events?

Development Programming & Scripting UI
, , , ,
1

Mouse events can be specified as either “Handled” or “Unhandled.” Since “Handled” blocks input to underlying widgets, I set it to “Unhandled” to allow those widgets to process the input.

I set the mouse events of the dragging widget to Unhandled so that the widget underneath could detect the cursor, but this caused the dragging functionality to stop working. It is clear that Unhandled is unilaterally configured to stop processing for that widget.

At this point, I needed a third option. the option of handling mouse events in that widget while also handling them in the widget beneath it.

Is there a way to do this?

2

Add interface to child widgets
Call it when an input is triggered on a draggable widget
???
PROFIT

3

i feel like you’re fighting the system though, if you create a drag/drop operation it should still detect widgets under the cursor

4

I really dislike this method because it adds unnecessary complexity, but compared to extremely unreliable mouse events, at least it actually works. I’ve overcome several problems using the same method before.

So, does that mean there’s no better way?

5

That wasn’t the case for me. It might be because I’m using Common UI.

The ambiguous behavior of mouse events is unpredictable. The limited number of options, combined with the endless combinations that constantly change the behavior, is frustrating.

6

ah yeah i dont use that, if you know c++ you can use Slate directly.

7

I realized that if you set OnMouseButtonDown to “Unhandled,” IsMouseButtonDown also always returns false. Why are they changing the rules without my permission? ■■■■■■■.

Furthermore, for some reason, IsInputKeyDown doesn’t work for left-clicking. What a pile of junk. When will widgets finally be able to correctly receive mouse input?