I’m trying to design a lesson that requires capturing values of a variable that’s based on student input, and then displaying the numberList of the history of that calculated variable.
For some reason, the history in numberList is always one click behind what the student has actually entered in the student input. In the link below, the graph should display:
- Red point: What the student has just submitted
- Purple point: The calculated value of the opposite of what the student submitted
- Blue point: The history of all the purple points.
But if you try it out, you’ll see that the blue points are always one click behind. Can anyone figure out what’s going on?
I think it’s always one behind because of the way the capturing is set up. The red points are displayed based on what is captured in the input, but the blue points are captured from the graph. I made two small adjustments to yours to make it work. I changed the numberList to come from the same capture as the red point, and then used (-N,0) as the list of points instead of (N,0).
Depending on your activity needs, you can opt to eliminate the action button and just use the “Submit” button from the input to act as the action button. Here’s an example.
Craig is right here, there shouldn’t be a need for a second button for this purpose. Does it serve another purpose on this screen? Your current set up has you capturing a captured “last value” which by design would make it one behind.
If you have use for the button elsewhere you can still keep all of your capture sinks in the input. Basically, whatever student action you want to capture should contain the capture sinks. Here, because students are entering a number into an input, put the captures there.
Thank you both, Jay and Craig. I was trying to mimic the behavior of the CL in much bigger activity, in which I do indeed capture a variable that’s defined based on a capture. I didn’t want to link to that activity here since it has so much code that it would take forever for you to understand it. But that double-capture was the source of my problems, and I’ve figured out a way around it.
I really appreciate your help.
I thought capture() always had to be in the Action Button CL. If I’m capturing from a table, will the activity actually run faster/better if I put the capture() sink in the table?
It’ll work in math inputs as well
Would you happen to have a sample of how you used it in a table? Thanks.