Add a macro for multiple choice checkbox answers.

[drgrice1]

This is intended to be a replacement for using PGchoicemacros.pl with new_checkbox_multiple_choice.

In order for this to work when used with a MultiAnswer object with singleResult true, the NAMED_ANS_CHECKBOX and NAMED_ANS_CHECKBOX_OPTION methods need to be updated to match the NAMED_ANS_RADIO and NAMED_ANS_RADIO_EXTENSION methods.

In addition, this fixes repeated ids on checkboxes created via NAMED_ANS_CHECKBOX_OPTION, and makes the coloring of checkboxes with incorrect and incorrect colors work as it does for almost all other answers.

Some example problems to test this are attached.
CheckboxListProblems.zip

Note that the choice-macros-checkbox.pg problem included in the above zip does not use the new macro, but uses the old new_checkbox_multiple_choice method. It is provided for comparison.

[Alex-Jordan]

Thanks for this. I am editing the PTX part, and in other way incorporating it into PTX.

To check that I understand things, if one uses labels =>"ABC", does it make sense to have the values also be "A", "B", ... etc? Or maybe I should ask: as long as labels are simple, is there any reason why the values should not equal the labels?

[drgrice1]

As long as the labels work (test them) they can be pretty much whatever you want them to be. I found that even latex math in the labels works fine. It is even typeset when you view answers on the past answers page.

[Alex-Jordan]

I'm having a hard time understanding when it is desirable (or necessary) for label to not equal the corresponding value. Can you describe a situation where they need to be different?

[drgrice1]

I have a specific case where they need to be different, but it is something out of the ordinary that I do. I was converting all of my parserRadioButtons.pl macro problems to use this new value option. What I did for most problems was create an array reference that I passed for both the answers and the values (wrapping that in another array reference for the answers so they would be randomized). So I started to think, why have this value option? Why not just use the answers? This is probably what you are thinking, right? Then I encountered my problems where I use a custom macro that creates an object that derives from a parserRadioButtons object, but the answers are javascript (JSXGraph images basically). That javascript does not work for the values.

Thinking further on it, I think that what could be done is to leave the new values option, but instead of using the old Bn values for the fallback, use the actual answer. So then if the answers work, they will just be used, but if the author provides an alternative value to use (because in testing the author realized the answers cause problems), then the provided alternative values will be used instead.

[drgrice1]

I should have omitted the comment about my derived package, because that really doesn't have much to do with what is discussed here. That merely adds some css styling to make the radio buttons work well with the javascript graph in a nice way.

[Alex-Jordan]

instead of using the old Bn values for the fallback, use the actual answer

I was thinking to use the label as the fallback (if there is one), not the answer. But yeah there are three things here: label, text, and value. And it's a bit hard to appreciate the need for all three. At least, in most situations.

I guess it's possible to have the label be the same (a bullet? but why do that?) for all the options, and then you'd want distinct things for the values.

[drgrice1]

The reason for the value option as requested by @drdrew42 and @dlglin was to provide a meaningful thing to show in the past answers table that does not depend on the randomization of the displayed answers. The old B0, B1, B2, ... answers don't have much meaning on the past answers table, but neither do labels like A, B, C, ... As a result, if the instructor wants to know what the student really answered, the instructor must open the original problem or do some hefty reverse engineering in scripts and such (for what @drdrew42 is doing). So that is why I was thinking the fallback would be the answers displayed for the students, since that has the same meaning in the past answers table that it does when displayed for the students in the original problem.

[Alex-Jordan]

I can imagine some issues if the answer text is long, and that is used as the default for the value. I can elaborate but you probably see what I mean.

So if you change things to make the answer text be the value, maybe that should only happen when the answer text is below some cap.

[Alex-Jordan]

Also I have to parse the concatenated string of values back into their components. It helps to have some level of confidence that the values themselves do not contain commas.

[drgrice1]

I am not sure what you mean by the concatenated string values? Checkbox answers are an array. For the webwork2 past_answers column they are joined separated by the unicode ⍮ character.