The Case of the Persistent Variables: a Lectora Mystery (Part 1)
It was a dark and stormy night, when I took on one of my most puzzling job, the Case of the Persistent Variables. The coppers had been investigating my old Nemesis, Professor Lessesmore, and they found something that had them stumped. It was a chess game built only in Lectora. You could move the pieces, remove any that were captured, and then rebuild the whole setup on return. I’ve worked this beat a long time, but this was something different. I knew in my gut it had to have something to do with persistent variables.
Sure, every rookie knows that variables can be used to retain the answers to quiz questions, or the completion status of a page, but I knew they could be used for much more. Such as, pass information, make comparisons, and rebuild a page on revisit. In short a kind of poor mans’ database. Just the kind of thing Lessesmore would use.
(Below… the chess set, built only in Lectora, rebuilds the last position on revisit of the page.)
My first task was to figure out how he managed to move the pieces. Lectora has built in Drag and Drop questions, but items can only be moved to a defined drop zone, and then they either snap to the drop location, or return to their original position if you miss the drop. That was certainly not how the Professor did it.
Since dragging was out, I thought about the “move to” action. A chessboard has 64 potential spaces, so there would have to be 64 buttons with a “move to” action and location (X/Y position) associated with each. I don’t mind some grunt work, but how could I pass the location to the correct piece? Lectora doesn’t have a way to dynamically target an object, and building a separate action for each of the pieces. Let’s see, 32 x 64? No, that doesn’t seem like my idea of a good time. How could I target the correct piece to move without building an action for every possibility?
Then the light bulb went off. Each piece could use an onClick action to set it’s “current” variable to “1.” Each square would set its X and Y position onClick, then run a set of “move” actions that would have a condition, to only target the “current” piece (the one set to “1”).
I still need to pass the X and Y location to the piece, but at least I’m getting closer.
But there’s one more problem; both the pieces and the squares need to occupy the same space, so only one can be clicked. Ah, but if the squares are transparent buttons (aka “triggers”) in a group at the top level of the page, that is shown after the piece is clicked, then the target square can be clicked, setting the X/Y position, and then running the “move” actions group, which would hide the squares group again. Fiendish!
I can see that Professor Lessesmore has really been at work on this one. Next time, I’ll explore how he was able to set the X/Y position with only one action on the trigger square, and reconstruct the game on return to the page.
(The chess board would need 64 buttons, but only two actions on each (see image below); one sets the X/Y value (more about that later) and the other runs the “move” group. An action on each piece runs the reset group setting the “current” value of all pieces to “0” before setting the one clicked to “1.” Only that piece will be affected when the “move” group runs, a kind of dynamic targeting.)
Read the next part of the series, The Case of the Persistent Variables: a Lectora Mystery (Part 2).