Mouse handle order

[ExBemined]

Hi,

I managed to click through a widget (again :ph34r:), in the following situation (tested on latest SDK 2.0 beta):

Place four windows parented to the same gui with overlap flag (don't use InterfaceWindow) behind each other so that they overlap. Click the background to unset the focus, and then try to click the front-most window, on a spot where all windows overlap. It will instead bring the last window that is behind to the front. It seems mouse events are handled in the same order as rendering, while it should be the reverse. So the first child widget gets rendered first, and the second child after that causing it to overlap the first one. Mouse events should then be handled the reverse way, the last rendered window first since it overlaps the rest.

[silent]

Hi Michiel,

 

Can it be reproduced with <SDK>/data/samples/widgets/ui_00 sample? If so, could you please give us some hints on sample modification in order to achieve described behavior?

 

Thanks!

[ExBemined]

Hi,

Yes I can reproduce it with that sample, even without modifications, just drag the four windows so they overlap each other and then click on the background to remove focus from the last window you dragged (since it seems the focus window is always first when it comes to mouse input). May have to hit escape to get the mouse cursor back after clicking the background, and then click the window:

[silent]

Thank you!

 

I've successfully reproduced this issue. Also I've added it to our internal bug tracker.