Hi, I’m developing a plugin and I’ve come across a strange problem:
My plugin adds a control to the bottom panel for settings, this control is the scene that loads the settings, receives the changes and finally saves them. I decided not to create a separate button for saving, so whenever the user changes any of the settings a function called save_changes is called (and I connected the signals of each option to this function).
The problem starts here, I have all types of nodes, including CheckBox, OptionButton & SpinBox but the OptionButtons are not sending any signals for some unknown reason, I tried printing a meaningless message to the console and I found that the OptionButton buttons are not sending any signals to this function, am I missing something?
@wyattbiker I use the user interface (Node > Signal) to connect them, and I connected the same signal.
Edit: Also I’m sure it’s connected, because I’ve also connected other buttons to the same function and they work, on the other hand, there are three OptionButtons I have in the list of nodes connected to the function, that’s what confused me!
You can try it this way:
Create a control scene and add an OptionButton to it, add a script to the control and put the @tool at the beginning and the following code at the end:
Select the OptionButton node and connect its item_selected signal to the save_changes, now add the scene to the menu using add_control_to_bottom_panel and see the bug, but if you try the normal buttons or checkboxes or spin boxes you will see that it works just fine.
I did this, but it only made the OptionButtons work, so I decided to create a helper function that takes the index and calls the main function regardless of the index, and I connected the option buttons to it.
Apparently the only problem was that the parameter sent from the signal was not received in the function, but I still have a question why the signal should be completely disconnected from a function that does not accept its parameters, is this a bug?
It is not a bug, and a warning/error should be logged when trying to do so. With type declarations it raises a hard question “How would the function handle being passed less arguments than required?” if you recommend passing null then a type error is raised anyways. And detecting this argument count (before the error) can be expensive, on every connection in a connection-heavy engine. Failing to connect is sadly the best option.
You can unbind(count: int) a function to drop arguments that would be passed.