Bug? Cursor is moved after clicking on "When mouse moves to top of screen" GUI

Started by monkey0506, Mon 19/06/2017 15:49:47

Previous topic - Next topic

monkey0506

After clicking on a GUI whose visibility is set in the editor as "When mouse moves to top of screen", the mouse cursor is repositioned to just below the GUI PopupYPos. This apparently happens no matter whether any script event is run, cursor mode is set, etc. The relevant script in the engine seems to be:

Engine/ac/gui.cpp#L290
Code: cpp
void process_interface_click(int ifce, int btn, int mbut) {
// ...
    if (rtype==kGUIAction_None) ; // line 290
// ...


But nowhere in that function nor any of the functions that call it does it apparently move the mouse cursor. I can understand the reasoning behind hiding the GUI if something actually happens, but if the click doesn't do anything then hiding the GUI seems to be counter-intuitive (e.g., player accidentally clicks on GUI background instead of button).

If it matters, I found this behavior on 3.4.1-b5.

monkey0506

The mouse is repositioned from remove_popup_interface, which is called from gui_on_mouse_up. Correction to the above: The mouse is only repositioned if clicking on an enabled GUI button, slider, listbox, or inventory window, after process_interface_click has been run. It still seems (to me) counter-intuitive to move the mouse and hide the GUI if the click didn't do anything though. However, I can't really think of any justification for an enabled control of these types with no associated action as a general case.

That said, I keep going back and forth on whether this should be considered as "by-design" or not. Is automatically moving the mouse like this actually something that should be hard-coded into the engine? Perhaps it would make more sense to expose the PopupAtMouseY and PopupStyle to the script API, and update the default template to preserve this behavior while not enforcing it at the engine level. :-\

Gurok

I think if people want custom "when mouse moves to top of screen" behaviour, they just use visibility normal and write their own handler for showing/hiding it.

That's kind of how I see the library routines. A good starting point, but if you want full control, you reimplement it as you like (provided the engine exposes enough for you to do so).
[img]http://7d4iqnx.gif;rWRLUuw.gi

monkey0506

Maybe so, but I still think it makes more sense to not have something like this hard-coded. It would be trivial to implement in the default template, whereas implementing custom "when mouse moves to top of screen" behavior is far less trivial (not "difficult" per se, but definitely less simple than the former).

It just wasn't expected, for a "No Action" button click to have side-effects.

SMF spam blocked by CleanTalk