I’ve just got used to defining the parameter variable before the parameter definition itself. Don’t see the issue, other than my decaying grey matter keeps forgetting.
@dave1707 because it doesn’t make logical sense in two ways:
- merely defining a function should not automatically trigger that function
- merely defining a UI control should not trigger that control
Definition and execution are logically separate processes that should be explicitly separate in parameter definitions, as they are everywhere else in lua.
@UberGoober I’m used to things not making logical sense, that’s life. You adapt or you die. That’s why I suggested something that can be set at startup as to whether you want the callback to execute at definition or not.
@dave1707 life is extremely uninterested in logic, true. I think you maybe just demonstrated that too by criticizing the appeal to logic followed by making a very logical suggestion. 
@dave1707 I’m also curious how you’ve been preventing automatic execution inside the callbacks themselves, and would love it if you wanted to share example code. Honestly before even bringing this up I tried to do that many different ways and none of them worked. You saying it’s super easy was surprising to me tbh.
@UberGoober It doesn’t matter to me what happens to the callback. If it’s done your way, I’ll make the change, if it’s done my way, I’ll make the change. That’s what programming is all about, making changes. Your way is logical, my way is something, I don’t know what. I’ve seen plenty of changes to Codea over the years, the hardest was the change to using the asset system. That took me forever to make all the changes, but I made them.
@dave1707 I should mention something else about the specific cases I’m using parameters in.
My project repeatedly resets the parameter list in response to user interaction, clearing it and then re-instantiating around 15+ different controls.
It’s been a nightmare having to account for some of those controls calling their callbacks when re-instantiating item, and some of them not, and actually changing some of them also as needed.
So any solution to preventing a callback from executing that only works by excluding the initial value won’t work in my case; they all have to be reset while retaining whatever value they’re currently set at and not calling the callback.
@UberGoober That makes sense. Since I don’t write anything important or that big, I don’t think I recreate the parameters list that much. If I do I probably use the callback to set something up anyways.
Perhaps you could include a boolean in each parameter call for enabled/disabled which defaults to enabled, but allows you to disable on running. Parameter.clear could set all to disabled or destroyed.
Given that we have a special case for buttons (parameter.action) where the action does not get fired on parameter declaration, I think it makes sense to extend this as the default behaviour across all parameter types
In the latest build (274), parameter should no longer trigger callbacks on initialisation. Let me know if this causes any issues
makes sense to me!