Now let’s play a bit. Suppose we have entered the values 1 through 6 as shown in Figure 108 and we want to replace the 6 with 7. If we press the Back button, change the 6 to 7 and press return, we get 6 instead of 7. The problem is that we need to copy the state of the Sudoku grid before making the cell assignment in
WebSudoku>>setCell: currentCell to: anInteger
sudoku := sudoku copy atCell: currentCell removeAllPossibilitiesBut: anInteger
If you change the definition of
setCell:to: and try to replace 6 with 7 you will get a stack error similar to that shown in Figure 115.
If you click on the debug link at the top of the stack trace and then look at your Pharo image, you will see that it has opened a debugger. Now you can check the problem. If you select the expression
self possibilitiesAt: aCell
and print it, you will get a possibility set with 6, which is the previous value you gave to the cell. The code of the method
MLSudoku>>verifyPossibility:for: raises an error if the new value is not among the possible values for that cell.
MLSudoku>>verifyPossibility: anInteger for: aCell
((self possibilitiesAt: aCell) includes: anInteger)
ifFalse: [ Error signal ]
In fact when you pressed the Back button, the Sudoku UI was refreshed but its model was still holding the old values. What we need to do is to indicate to Seaside that when we press the Back button the state of the model should be kept in sync and rollback to the corresponding older version. We do so by defining the method
states which returns the elements that should be kept in sync.
^ Array with: self