Hi!
Do all mouse clicks on GUI buttons push them before processing? I'm trying to be able to right-click cycle while over a button, but the button always processes the right-click as a push and shows the "pushedimage". I've tried tweaking the on_event and on_mouse_click functions to disable the button or change the image, but it looks like the mouse click is processed before the function runs.
Is there a way to make buttons ignore right-clicks? My alternative solution is to create two buttons, one for function, and a dummy one for visuals. But I would like to know if there's a simple solution I'm overlooking first.
Thanks!
Please clarify which is your intent, because it's not just pushed image, the buttons will actually run their action on either click, left or right. Is that okay with you, and you just want to not have it show pushed image with the right click? Or do you want the button to not trigger on right click at all?
I don't think there's any setting that will disable button reacting to a right click. But you don't need 2 buttons for a workaround, you may use 1 button without a PushedImage, and change its image temporarily following the left mouse down. I suppose this may be scripted globally for multiple or all buttons in the game.
That sounds like an annoying necessity though. I wonder if that's a design oversight in this engine, and how come there are not many requests like this...
EDIT: i think even middle click triggers gui buttons.
EDIT: and not only buttons, but other controls react to right click too: such as sliders and list boxes.
Aha - thanks for the idea! I've been fighting the RMB all night, but it was as simple as updating the pushed graphic in the on_event.
I think the problem stems from trying to make a hybrid Sierra/LucasArts GUI. I wanted the RMB to only cycle through cursors, while allowing the LMB to interact freely with the GUI, but the GUI wanted to treat both buttons as the same. Now that I have one button working, I can probably make something more global with this.
function on_event(EventType event, int data) {
if (mouse.IsButtonDown(eMouseLeft)) { {
btnWalk.PushedGraphic = 99; // Set the button to pushed
}
if (mouse.IsButtonDown(eMouseRight)) {
btnWalk.PushedGraphic = 98; // Set the button to normal
}
}
Thanks again!
When you click on a GUI, on_event is called with eEventGUIMouseDown as the first parameter, so you should probably wrap your code inside that (although it doesn't make that much of a difference).
You should also check which button if any is under the mouse (using GUIControl.GetAtScreenXY).
I tried to implement a generic solution that stores all .PushedGraphic values in an array, then sets them to -1. My code also calls on_mouse_click(eMouseRight), i.e. automatically redirects the click to be handled as a non-GUI one.
Everything works so far, the only (major) issue is that there seems to be no way to prevent the button's OnClick from running other than to manually exit it in each handler separately based on a dont_handle variable. Possible to do but kind of annoying.
So how this can be solved in the engine, in the short term at least?
Suppose I add a game-wide setting that tells which mouse button should gui controls react to? Where 0 would mean "any" (compatible default) and mouse button code will restrict their reaction to that button.
Generic events such as eEventGUIMouseDown and eEventGUIMouseUp will run always.
Not sure what the best solution is; maybe something like this in the templates, which people can now override however they want:
function on_mouse_gui_click(MouseButton button)
{
if (button == eMouseLeft)
{
GUI.ProcessClick(mouse.x, mouse.y, Mouse.Mode);
}
}
As an experiment, I am adding a new settings to AGS 3.6.2, called simply "GUI controls handle only left mouse button".
It's "false" by default, in which case engine will pass any mouse down and up into gui controls, and if it's "true" then it will pass only left mouse events.
on_event will still be called with eEventGUIMouseDown and eEventGUIMouseUp for all buttons regardless. This option only restricts automatic gui reaction.