Is there a way tie the math response sink “disableEdit” to conditions other than the pressing of that math response’s submit button? The CL seems to accept the coding of conditions (like time since press of other action buttons, etc.) but then does not work when those conditions are met…?
I couldn’t get it to work either. It looks like it only works with the response button and not with an action button. For example, you can set it to true, you type something, and submitting then activates the disable. This seems like what you want by your setup in screen 1. Putting a condition (like >20), I can continue to edit and submit until I type something >20.
If you want a similar function, you can hide the math response box (and the action button if you like) once the button is pressed, then have a note appear with the student’s response.
Thank you for the response. I should have indicated in my original post what I was hoping to accomplish. I would like students to submit their response, the input become disabled but still visible so students can read my feedback while seeing the answer they input, and then they can unlock the input using an action button (which I can track how many times it has been pressed). Just not sure why the disabled feature can’t be tied to anything other than the submission button of the input itself…
The disableSubmit only applies to the math input and its submit button because clicking that button tells the code “this input is submitted” with all that that implies. Action buttons don’t have any behind-the-scenes code other than “this button has been clicked” because they aren’t tied to a specific component. That’s the trade-off with flexible code.
To renable editing, I would tie the hidden true/false to pressCount instead of the time since press and add a second action button. Look at the new first screen of the activity:
disableEdit with action buttons, now with max # of edits
I think I currently have this set at max 2 edits, but you can change that (or delete it if you don’t want a limit). [I’ve also cleaned up my code a bit so you only need to change most of the variables in one component.]
Is there a reason you want to use an action button instead of the built-in submit button? You can easily change the code to do what the first action button does, plus you can take advantage of the capture and history features of the submit button. You could list the student’s previous answers so they (and you) can see the progression. [I haven’t played with those components yet; I might continue tinkering because I’m procrastinating getting my lesson plans ready for next week.]
Yup, totally procrastinated. I… may have gone overboard. It turns out that capture and history only work with numerical values, which makes me a bit sad. However, you can use them with either math response or action buttons, so I’ve thrown together some slides to show what those look like.
The first two screens use two action buttons for submit and unsubmit and are practically the same; the second one counts down the number of edits left. [These are both currently set to a max of 2 edits, but you can make that virtually unlimited by changing the value of maxEdits in the var component to 50 or above.]
The 3rd screen is way too cluttered; it’s showing the capture history in a different ways. I’ve set it to “unlimited” edits. [If you want true unlimited edits, you can just comment out or delete the related code in the enableEditButton component; in the current version it stops at 50 edits. I assume. I haven’t had the patience to check. ;).]
The 4th and 5th screens replicates the 2nd and 3rd screens using the built-in math input Submit button. The capture history on the 5th screen is much less cluttered.
1 Like