no doubt you are initializing this parameter inside the setup function yes?
i noticed the setup function gets called by codea twice (a good reason to avoid using setup)
parameters with callbacks get triggered during initiation also (my guess is this to keep the expectation that the callback will run with the initial value as well as when you change the value)
so you’re seeing “oops” twice because the callback is triggered by the initial value and setup runs twice
these are some of the reasons why i do not like parameters and setup, my goal is to eventually never use parameters. i only use setup to call a wrapper class i name App whose init kicks off the initial loading screen, after that i push all my subsequent loading and custom parameters into the draw function (by partitioning draw with internal loops and that Thread class from the other topic)
i believe this approach is called Inversion of Control. and it just makes sense that you want to be able to control what is visible to the player (like company logos, main menu screen) without having to wait for setup to run, and to have your own debug menu/options/cheats that are not bound to the limits of parameters
@UberGoober@RonJeffries At the start of this discussion I stated that it will print twice. Why I don’t know, but it does and has always done so for a long as I remember. As for a parameter callback function, it always gets executed once when the program starts. In my projects that have parameter callbacks, I also have code to check for that first call and make sure I don’t process anything if it shouldn’t.
So here’s what I’ve known about for a long time.
1). Codea runs thru the code twice before it executes the setup() function.
2). Parameters in setup() that have callbacks will execute that callback when the program starts even though the parameter isn’t used yet.
I don’t know why, but that’s what happens and that’s what I code for if I need to. I don’t think it’s ever been documented, but at some point I probably asked about it. There’s other things I’ve come across that seemed odd, but that’s the way Codea works.
Try this code.
function setup()
parameter.integer("xxx",1,5,aaa)
parameter.integer("yyy",1,5,bbb)
parameter.integer("zzz",1,5,ccc)
end
function aaa()
print("aaa")
end
function bbb()
print("bbb")
end
function ccc()
print("ccc")
end
@dave1707 yep you’re right, i’ll leave my previous message mostly intact, but setup is not being called twice
print("before setup")
function setup()
print("setup")
end
print("before draw")
function draw()
print("draw")
-- This sets a dark background color
background(40, 40, 50)
end
print("after both")
i guess because the parameter is being initialized in a function that is called twice?? another good reason to put loading logic into draw
@RonJeffries Probably what Codea has to do before it can start running any code. Could be similar to a two pass compiler. To me it doesn’t matter how many times it does it because there are very few commands I put outside of any function. Currently the one I use most is “viewer.mode=…”
@UberGoober Yes, I’ve adapted to Codea’s quirks because apparently that’s the way Codea works. Maybe some update will change that, and I will adapt to that. Just like the way assets are now coded. I’ve changed all my projects and I’m sure you’ve changed all your projects to account for that. Some things change and some things don’t and some thing are just the way they are.
@UberGoober Thats how you learn, or at least that’s how I learn. I keep poking around until I figure out what’s happening. That’s what I enjoy about coding.
@dave1707 sure, and there’s lots to be learned from obstacle courses, too.
At times Codea is a fun way to make cool things, and at times it’s an obstacle course.
It often seems like you defend difficulty for difficulty’s sake; have you ever learned something and then thought, gee, it would be great to help other people learn this more easily?
@UberGoober Would I help other people learn something more easily, NO. It was hard for me to learn, so it’s going to be hard for you. Past experience shows me that people who are just given things don’t appreciate them. If you don’t work for it then it has no value to you. When you break it, you expect to be given another one no matter how expensive it was to begin with. Just kidding. How was that for defending difficult for difficulty’s sake. Of course I’ll help, but I don’t know what to help with until someone asks. I try to explain things to the best of my knowledge, but I can only explain what I figured out.
I would classify this behaviour as a bug (running things twice). Codea does run the code twice, but the first pass being hooked up to the output system / UI is the bug
I’m not sure if I’d classify executing the parameter callback on initial setup as a bug. I can’t decide if the behaviour is useful or not, and technically, you could consider it a value change (the value has gone from nil to whatever the initial value of the parameter is)
@Simeon I think the rubric I suggested is useful: when you declare a button that has a callback, do you expect the callback to be run without a user pressing it?
I think most people would say no, a button should only execute its callback when a user presses it.
Similarly, for any piece of UI, defining what it does during interaction should not itself be treated as an interaction.
@Simeon also, about usefulness: if the programmer wants a parameter’s callback to be run at the same time the parameter is declared, that is in their control at any time; they can make that happen just by regular coding.
But by making the callback run automatically you remove the programmer’s choice in the matter.
@Simeon I have code where I want the callback to be executed when the parameter is defined. That way things are set the way I want when the code is executed. I realize sometimes you don’t want it executed at startup, so maybe there can be a parameter that get set something like “viewer.mode=FULLSCREEN” does at the start. Something like “callback=true” to run it at definition and “callback=false” or not coded as the default, to not execute a callback at startup.
@UberGoober But why do I have to add code to execute a callback when it executes to begin with. Why can you add code to your callback function to ignore the first callback.