Mouse and keypress consume

[hiflyer]

When I was trying to figure out why our game fails to get keyup in some cases where the mouse pointer is over UI components I realized that the offerInputToUI method in UIHud uses the same boolean flag for mouse and key events when determining whether to propagate the input states or not.
The effect of that is that when a key is released at the same time the mouse moves over a component that handles mouse events it will be considered consumed and our game will never see it.

I wrote a simple patch that seems to solve the problem but it's quite possible that you can solve it in some other way with a bigger redesign.

[hiflyer]

Any input on this?

[gouessej]

Hi

I find your fix quite fine. Why did you think about a deeper code redesign?

[renanse]

It looks like a good idea, but seems to have some flaws... For example, try running SimpleUIExample after your patch and then drag the UI frame around.

[hiflyer]

I see. That's clearly not working as intended. We don't have that particular problem with draggable frames in Spaced however so I'll have a look at what we are doing to prevent it.

[hiflyer]

When there is a draglistener, the ui should consume mouse input (imo) so I changed line 625 in my patched version of UIHud to

Code: Select all

return consumed || _dragListener != null;

. That fixed the problem. Do you see any other bug with it?

[renanse]

Unfortunately now the mouse look on the main scene does not respond properly (it drags out of control, spins the view when I'm not dragging, etc.) Do you see that on your end?

[renanse]

Ok, I've got it nailed down. The issue was in fact object equality like you guessed, but we currently rely on that to determine if dx, dy and dwheel are valid for the current frame. The fix was to avoid additional object creation if we aren't actually consuming anything, which seems to work reasonably well. Please test in spaced when you can as well. And thanks!

[hiflyer]

The fix works fine in spaced. Thanks for tracking it down.