Jibble

Author Topic: Bug? Cursor is moved after clicking on "When mouse moves to top of screen" GUI  (Read 1436 times)

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
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: C++
  1. void process_interface_click(int ifce, int btn, int mbut) {
  2. // ...
  3.     if (rtype==kGUIAction_None) ; // line 290
  4. // ...

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

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
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

  • Rottwheelers
  • When life hands you lemons, combine them with the mop
    • I can help with AGS tutoring
    • Best Innovation Award Winner 2016, for improving and extending the AGS scripting language
    • I can help with proof reading
    • I can help with scripting
    • Gurok worked on one or more games that won an AGS Award!
    •  
    • Gurok worked on one or more games that was nominated for an AGS Award!
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).

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
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.