Page 1 of 1
[0.12.29] [kovarex] clicked_background ignored on right clck
Posted: Thu Apr 21, 2016 2:20 am
by JasonC
Right-clicking on a checkbox (created by a mod) generates the on_gui_click event, but does not switch the graphic to the clicked_background graphic while the mouse is down, it leaves it on hovered_background.
The bug is that either a) checkboxes are responding to right-clicks when they should not, or b) checkboxes aren't displaying the correct graphic during a right-click.
Minor issue.
Re: [0.12.29] Right click checkbox doesn't change graphic
Posted: Thu Apr 21, 2016 4:06 pm
by Klonan
Thanks for the report
I reproduced this using some in game script
Right clicking a gui checkbox triggers the on_gui_click event
Code used to reproduce it
Code: Select all
/c p = game.local_player p.gui.top.add{type = "checkbox", name = check, state = false} script.on_event(defines.events.on_gui_click, function(event) p.print("check") end)
Re: [0.12.29] [kovarex] Right clicking GUI checkbox triggers on_gui_click
Posted: Fri Apr 22, 2016 1:42 pm
by kovarex
This is actually not a bug, as the event just says, that the user clicked the element, not that it changed its state, you can track gui click on windows, labels etc.
If you want to track whether the user actually changed the state of the checkbox you can use the event .... ah, it doesn't exist yet.
So I added new events on_gui_text_changed and on_gui_checked_state_changed for 0.13
Re: [0.12.29] [kovarex] Right clicking GUI checkbox triggers on_gui_click
Posted: Fri Apr 22, 2016 7:28 pm
by JasonC
kovarex wrote:This is actually not a bug, as the event just says, that the user clicked the element, not that it changed its state, you can track gui click on windows, labels etc.
My report was mostly related to the graphic not changing but I think I understand your view of it: The real "issue" was just that right-clicks generate a click event even though they don't change the check state, and the upcoming change is that since there wasn't really an event dedicated to checking for a check state, one is being added.
Another option could be to just not have GUI click events (despite their name) respond to events that don't also lead to visible state changes in the button, since that would keep the event consistent with UI visual feedback.
But, sounds good, thanks.