Two sessions
If you are accustomed to working in a terminal session for running your application, looking at global data, etc, it is best to start two terminal sessions when using Serenji. The first session should be connected to Serenji and used just for editing and debugging; in the second you can work normally.
To allow Serenji to be used for both editing and debugging it is best to start it using the SHELL entry point, eg
USER>DO SHELL^%Serenji()
sUSER>
This way, you are able to edit code in Serenji, but can also debug a program whenever you like just by setting breakpoints and running it from the shell prompt, eg
sUSER>d ^myProgram
Only use the Shell for debugging programs and editing
Avoid running programs such as %G from the Serenji shell prompt because the Serenji File Open and File Save functions are disabled while a program is running. It is very easy to forget this and leave the running program at a read prompt (eg at the Global prompt if you are running %G). Also, programs run from the shell prompt will run more slowly than normal, unless started with the GO command rather than DO.
Close Stack, Variables, Immediate mode and Breakpoint windows
It is a good idea to close all of these windows for normal use. By closing them you will have a larger usable area for editing and reading the code, and, when debugging, it is much faster for single-stepping through code.
You should also maximise Serenji and maximize the code windows within Serenji. If you close Serenji with your preferred window settings, it will automatically save them for future sessions.
If you really want to maximize the space available for code windows, consider switching off some or all of the toolbars (View /Toolbars menu option). All of the toolbar buttons are available from the pulldown menus and many of them can also be invoked using standard keyboard shortcuts (eg Ctrl-S for save).
Break on Error
If your application regularly uses error handling to trap expected errors (eg to detect and handle end-of-file conditions), it is a good idea to disable the Break-on-Error feature until such time as you need it (Debug /Break on Error menu option).
This will prevent Serenji from stopping whenever your application encounters an expected error that it is designed to handle.
The Edit-Test cycle
Most development comprises of an iterative edit-test cycle with occasional debug sessions. Traditionally, if you are using a single terminal session with a character-based editor, you would run the editor, open your routine, make changes, close the editor and then test your program. Using Serenji, you can leave the routine open in the editor and test your program in the second session. When you need to make further edits, the routine is already open in the Serenji session. This dramatically increases the speed of the edit-test cycle.
The Edit-Debug cycle
If you use Serenji for editing, it is highly likely that when you need to debug the routine you are working on, it will already be open in Serenji. To debug, all you have to do is set a breakpoint by clicking in the left-hand margin and then run your program from the Serenji shell prompt.
If you used a different editor for making code changes, you would have to fire up Serenji and open the appropriate routine before you could start to set breakpoints.
Learn the keyboard shortcuts
As with any GUI interface, productivity in Serenji is significantly improved if you take the time and trouble to learn a few keyboard shortcuts. Here are some useful ones, in order of importance, for working with Serenji:
| General | Switch between windows | Alt-Tab |
|---|
| Editing | File /Open | Ctrl-O or Alt-F,O |
|---|
| | File /Save | Ctrl-S or Alt-F,S |
|---|
| Debugging | Step Into | F8 |
|---|
| | Step Over | Shift-F8 |
|---|
There are others, but learn these five first.
