The current version of WeBWorK is 2.18.
The draggableProof.pl macro you are using with WeBWorK 2.15 (if there is not one in the course templates directory) would be the one in the OPL. That version was rather old and didn't work well. The only fix that I know of would be to use the macro with newer versions of WeBWorK.
I tried putting the latest draggableProofs.pl in my macros folder (from the new development: https://github.com/openwebwork/pg/blob/main/macros/math/draggableProof.pl) but then I get other errors about ADD_JS_FILE not being present. Deleting these ADD_JS_FILE lines and trying to place these files appropriately in my course also does not seem to be easy, as I don't know where to place them correctly (if it's even possible).
Thanks!
Paul
Ok, I have an idea for a possible temporary solution, but I don't understand the code well enough to know how to implement it.
It appears that the options in the left column are kept the same, if saved, or recreated as the complement of the right column, if not.
Since sometimes the right column is going blank (and thus losing all those options), I want to make the left column always be the complement of the right side. This should do the trick, as a stop-gap, as my students will always have all the options to work with. (Right now the options that disappeared are not available to continue working on the problem.)
Here's the code that I believe is relevant in the github version of draggableProof.pl. In particular it appears that the last code block below needs the adjustment.
sub GetAnswer { my $self = shift; my $previous; # Retrieve the previous state of the right column. $previous = $main::inputs_ref->{$self->{tgtAns}} || ""; $previous =~ s/$self->{id}-//g; $self->{previousTarget} = [split(/,/,$previous)]; # Calculate the complement of the right column. my %prevTarget = map {$_ => 1} @{$self->{previousTarget}}; my @diff = grep {not $prevTarget{$_}} (0..$self->{numProvided}-1); # If the previous state of the left column has been saved, use it. (This ensures that the tiles # in the left column are kept in the same order that the user had arranged them). If it has not # been saved, use the complement of the right column. $previous = $main::inputs_ref->{$self->{srcAns}} || "$self->{id}-".join(",$self->{id}-",@diff); $previous =~ s/$self->{id}-//g; $self->{previousSource} = [split(/,/,$previous)]; }
What should I change so the left column is always the complement of the right column?
Thanks so much!
Paul
This line:
$previous = $main::inputs_ref->{$self->{srcAns}} || "$self->{id}-".join(",$self->{id}-",@diff);
Is like:
$previous = A || B;
That means if A is true in the perl sense, $previous will be set to A. Otherwise if B is true, then B. So I'm guessing from the comment above you would just remove the A portion and see if that works for what you want.
This worked! The left side now repopulates with all the elements when the right side goes blank after the second submit of the same ordering.
But it would be even better if I could keep the problem from blanking out the right column on the second submit of the same answer in the first place. Do you have any ideas how to accomplish this in the OPL github version of draggableProofs.pl?
Again this is just a stop-gap solution for use in older versions of WeBWorK, but I'd guess some other people may be in a similar situation. I had thought the draggable proofs had been a fairly stable problem type for a number of years. But I had not used one before this semester.
Thanks so much!
Paul
Unfortunately, the version of the draggableProofs.pl macro in the OPL has lots of problems. That is why it was rewritten (twice now). The updated macro no longer uses the obsolete jquery nestable library, and uses a more modern drag and drop javascript library. It also works in gateway tests, and the OPL version did not. The updated macro also uses PG Perl modules (lib/DragNDrop.pm), and so it would be rather challenging to backport it to older versions of WeBWorK.
I am sorry, but I don't want to revisit the old version of that macro and try to fix it again. The newer version is so much better.
I can understand.
The fix Alex helped me work out makes these problems usable for now, if a little buggy. I am glad that this type of problem is finally going to be stable in the newest versions of WeBWorK (2.17 or newer). It's been a really impressive-looking problem type for years.
Paul