If your code runs without opening a debugger but returns the wrong answer, there are two ways to debug the problem: add a halt to your code or set a breakpoint in the script. After adding a halt or breakpoint to your code, you can use the debugger to see what scripts and objects your code is using.
Adding a halt
For example, suppose you want to see what scripts and objects are used for code that defines a small dictionary. Insert halt or self halt in the code so it looks like the following:
(Dictionary new) halt; at: 1 put: 'Sam'; at: 2 put: 'Mary'; at: 3 put: 6; at: 9 put: (Date today); yourself.
Next, run the code (highlight it and select Inspect).
Adding a breakpoint
Instead of using halt, you can add a breakpoint in your script. To add a breakpoint, do the following:
You cannot insert a breakpoint in a Doit method. Nor can you set a breakpoint on entry to a primitive method; however, breakpoints are supported in primitive fail code.
For most breakpoints, you will likely want to take the defaults of for the process and iteration constraints and true for the expression constraint.
The breakpoint is highlighted and a dot appears beside the browser's description pane.
For example, use a script such as TestMonth below to try a breakpoint.
testMonth "Print month values for Month drop-down list (m1) and DateMonth (m2) text field." | m1 m2 | m1 := (self subpartNamed: 'Month') object. m2 := (self subpartNamed: 'DateMonth') object. Transcript cr; show: m1 printString. Transcript cr; show: m2 printString.
After a debugger opens, select the message that caused the error from the message stack (middle-left pane). For this example, select UndefinedObject>>#Doit. Notice that halt is highlighted in the bottom pane. Now, individually select the push buttons in the middle of the debugger. They offer four ways of stepping through the code: