initialize_input() is only called once during activation, so wouldn’t have an affect later when a calibration is called. I just reviewed all the code executed and I can see no reason why you would experience different behaviors. The frontend should not be able to load until the calibration function has finished executing, at which point the new values would already be stored in the database.
I’ll create a test Input and experiment later. It’s desirable to have consistent behavior, and I would like to know what circumstances are responsible for the altered behavior.
So, I tried importing my old custom input again (changed the name to avoid conflicts). I don’t see the old behavior any more – it behaves exactly the same as your revised version. Perhaps I’m misremembering, or the behavior changed between v8.9.2->master.
So I reviewed the code and conducted some tests. When a Custom Action button is pressed for an Input, a thread is spawned that executes the specified function in the Input. It does not wait for the function to complete before the web UI is reloaded as I originally thought. This means, depending on how long it takes for the function to execute, the web UI may or may not reload before the function completes. Because of this, you may see, for this particular Input, the new value display in the web UI immediately after pressing the button, or you may have to refresh the page to see the updated value.
Now, I do see value in allowing the user to specify whether a thread is spawned for the function or if the web UI should wait until the function completes before reloading. If a thread is not spawned, you can even return information to the UI for the user to read, such as a status message. So, I modified the system to allow this to happen. For Custom Action buttons, there is now the optional option “wait_for_return”, which when set True will not spawn a thread and will instead wait for the function to end and display in the UI status message the string that is returned. If your Custom Action is a long-running process, it makes sense to use the default behavior and set “wait_for_return” to False (or don’t even include the option, which defaults to False).
All the calibration Actions now have “wait_for_return” set True so the Custom Options will always be immediately updated with the calibrated values after the UI reloads and there won’t be any variability in this behavior as there was previously.