The debug window is shown at the bottom of an keyboard editor when debugging the keyboard. It is made up of three parts: The Debug Input box, the Debug State box, and the command and status bar above them.
The debug input box is used for typing input to test the keyboard. It will display the output exactly as it will appear in use, except for deadkeys, which are shown visually here with a symbol.
The test mode lets you test your keyboard without the debugger being active. This lets you test functionality that is not available within the debugger - primarily IMX code.
Once the test window is open, you can switch the keyboard between ANSI and Unicode mode with the radio buttons in the test toolbar. You can also switch on debugging mode (which is probably too verbose at present for general use) and switch the keyboard on and off with the Keyboard Active checkbox.
You can see the character codes for the current or selected characters in the status bar, which can be useful when debugging your keyboard.
The debug state box shows the internal state of the keyboard interpreter.
This shows the elements that make up rule currently being processed: the context, the key, and also what the output will be. If the rule uses stores, the contents of the store will be shown in the right-hand column, with the matched letter in red.
Here all the lines that have been processed to this point are shown in a list. You can double-click on any entry in the list to display the line in the keyboard source.
This lists all the deadkeys that are currently in the context. You can select one from the list to see it highlighted in the debug input box.
The idea in regression testing is to record a sequence of keystrokes and the output the keyboard produced, in order to test for the same behaviour on different systems.
Use Start Log/Stop Log to record the input and output. You can then use Run Test to run the test again, or go the Options menu to clear the log, or save or load a test, or use the batch mode to run several tests in a row.
If the output produced while running a test is different to that stored when recording it, Keyman will halt the test on the line where the failure occurred, and activate Single Step mode.
The command and status bar controls the debugger and shows information relevant to it. The Single Step button enables single step mode; when it is on, Keyman will process the keyboard file one line at a time, waiting for you to click Step to go to the next step or Run to finish processing the current keystroke immediately. While in single step mode, the current keystroke will be shown in the right-hand side of the bar.
Use the Pause button or press Shift+Esc to pause the debugger. When the debugger is paused, it will not accept any input, and ordinary shortcut keys (Shift+F5, Alt+Tab, etc.) will function as usual. Press Pause again to resume debugging.
The input status is shown beside the Pause button. It can show one of the following messages:
|Ready for input||The debugger is waiting for more input|
|Focused for input||The debugger is waiting for more input, and the Debug Input window is active|
|Paused||The debugger is paused|
|Receiving events||The debugger is processing input|
|Debugging||The debugger is active during Single Step mode or after a breakpoint|
The system keyboard layout currently being used is shown next. You can test your keyboard with a different underlying layout by selectingfrom the menu.