Couldn’t answer in your thread because only staff can reply there, but I’m pretty sure that your task is actually starting. The problem lies in your if statements in that task. You’re checking if the string equals something using ==, which only works for primitive variable types, so if you want to check if two strings are equal to each other, you have to use the strcmp(string x, string y) method. When two strings are equal in value, it will return 0. So, something like:
if(strcmp(controlType, “arcade”) == 0)
would work just fine.
Also, your wait10Msec(2) is supposed to be at the end of the whole loop itself, not inside of your if statement.
Also true lol, you have to change the second if statement to an “else if” statement so that it skips it if the first one happens. Otherwise, it’ll run the first, then the second, and it’ll always stay arcade.
I think my solution to that in my own code is that when the button is pressed, wait 500 ms before the next iteration of the loop so that it doesn’t check again for a bit, but there’s other ways to solve this.
You could just not do any action until the button is released. There’s many different ways to circumvent this.
This means only activate when the button state changes from not pressed to pressed. It allows you to track the press action instead of just when the button is down.
Unfortunately that won’t work either, because when you set lastButton = vexRT[Btn5U], it sets the current value of the button (0 or 1), not the actual button itself.
Yup. I prefer that technique because I can use it in a lot of places without ever having to worry about the time a button is held down or pausing all of the other code in a task.
Of course this takes a tiny bit of ram to store the value and the time to write the variable every loop. Neither of which are really big costs.
There are definitely times in programs where
if(button{
//stuff
while(button){}
}
would be catastrophic. An easy example being detecting the press of a button on the robot instead of on the joystick, we can’t know how long that button will be pressed. It is just easier to use the same technique every time than to switch back and forth.
Agreed. I may actually end up using this in my code just because it’s instantaneously faster than waiting until the button is released, and every millisecond counts when you’re going for the skills world record haha.
Since I’ve been pointing it out in other threads, why not here, too. This is a nice solution, and it works pretty well because of the speed code moves compared to the human user, but as a general policy it’s risky:
You don’t want to collect data from a sensor twice with the assumption that it will actually be the same data. Consider what happens in the scenario:
If statement gets checked just before Btn5U is registered as true.
Btn5U is registered as true.
lastButton gets set to true since Btn5U is true.
You cycle back around with Btn5U still pressed and so true.
The if statement does not register because it thinks it did the prior time around.
lastButton remains true.
Repeat 5 & 6 forever until you let go.
The code will never properly recognize that Btn5U had been pressed after it had not been.
This is the same good idea with that problem fixed:
Yup, agreed it is a race condition. While not mattering very often it definitely would be a confusing problem to debug when it did happen. No point giving an example that can fail.