What's the deal with on_mouse_click ?

[Monsieur OUXX]

AGS 3.4.1.13 (that is 3.4.1 patch 2)

I have that GUI that I've made clickable. Inside a module, I have on_mouse_click and on_event.

Turns out on_mouse_click does detect the mouse wheel being "clicked" but not the regular left click.
For that, I have to resort to on_event (but then I don't know which button was clicked).

Is it still the aftermath of interface_click having been made obsolete? What's the proper of doing it?

[Crimson Wizard]

I cannot tell what was the original plan with events, but only the fact is that mouse_click currently does not react to clicking on GUI.
Reacting to the mouse wheel click on GUI is news to me.

"on_event" is perhaps the right way to handle left/right mouse clicks on GUI at the moment.

Is it still the aftermath of interface_click having been made obsolete?

Not sure what is implied by this question, since I did not use AGS at the times when interface_click was still on.

Looking at the engine code, interface_click was deprecated in favor of using GUI event handlers, but the problem is that there is not enough events to fully cover all cases. For instance, interface_click seem to had been called for Sliders, TextBoxes and ListBoxes, but these controls do not have OnClick now. Slider and ListBox have "OnChange" but that is not technically the same thing. TextBox does not have even that.

[Monsieur OUXX]

Well at the moment it's really weird because I have to resort to two separate functions to manage my GUI :
on_event for the click
on_mouse_click for the mouse wheel.

Also the weird thing is that I *think* that on_mouse_click succeeds in capturing the GUI clicks when it's placed in the global script (and the GUI is made clickable), but not in a module.

Food for thought (I don't want to distract your attention and effort from the important things, that's cleary secondary) but here is how I would do it :
- rename on_mouse_click to on_ingame_mouse_click
- re-introduce interface_click as on_gui_mouse_click
- Pimp up the events system. At the moment it's really poor. A secondary parameter to give more data (e.g. "which button") could save lives.
Then again I haven't given it too much thought so don't be outraged by my statements

[morganw]

GUIs have an OnClick event (for the GUI itself) and that can only be in the global script. I've had similar problems recently, and the best I could do was have a generic function to assign to OnClick events, which just just passed the data back to the module:
https://github.com/adventuregamestudio/ags-template-source/blob/master/Verb%20Coin/GlobalScript.asc#L234-L238

I also had to resort to using OnEvent for some things though, due to lack of built in click handling:
https://github.com/adventuregamestudio/ags-template-source/blob/master/Verb%20Coin/VerbCoin.asc#L463-L480

[Crimson Wizard]

Also the weird thing is that I *think* that on_mouse_click succeeds in capturing the GUI clicks when it's placed in the global script (and the GUI is made clickable), but not in a module.

You may confirm this? I don't think it is supposed to have such difference.

Food for thought (I don't want to distract your attention and effort from the important things, that's cleary secondary) but here is how I would do it :
- rename on_mouse_click to on_ingame_mouse_click
...

There may be a need to separately discuss and write down a concept for the future revamp of these functions. If we are speaking of big changes, it's perhaps better to approach this as from the clean page and just describe what we want (and leave implementation and compatibility problems for later).
But on_mouse_click is currently special in that it not only handles "in game" clicks, but also clicks on inventory items. See this ticket on the github (also illustrates different opinions on the issue): https://github.com/adventuregamestudio/ags/issues/472

[Monsieur OUXX]

See this ticket on the github (also illustrates different opinions on the issue): https://github.com/adventuregamestudio/ags/issues/472

Thanks.

@morganw : this discussion is outside of the scope of Editor-hooked events. Thanks though.