Please visit the sponsor of this series, and don't forget to say where you heard of them!

---

The Absolute Beginners Guide to OPL

Part 23 - Setting up

---

Please ensure you have the latest version (1.4) of the RMREvent example program before reading through this tutorial. If you use an older version, some of the text may not make sense.

We'll carry on with the two set-up lines, starting Program$="RMREvent". Putting a program name and version into specific variables is an extremely good habit to get into as it means that you can easily modify them at a later stage without having to remember (or search for) all instances of quoting these details throughout the program.

Onto the first real procedure of the application, Init:. Again, putting all those definitions, defaults and setting-up tasks in one single place is a very good habit and will pay dividends in the future. Generally, the more you use OPL's procedures to bundle up specific tasks and groups of operations, the more easily your code will be to understand [e.g. when you come back to it in a year's time to make a small modification, or when you hand the code over to someone else]. The only exception to this rule of thumb is when programming games which need every bit of speed available, in which case it's sometimes OK (if you know what you're doing) to put repeated chunks of critical code 'in-line' in the main procedure rather than breaking it up into smaller procedures.

Let's look closer at Init: (short for "Initialise") and discover exactly what it's doing. Find PROC Init: (about 30% through the main file):

Into an initialisation procedure should go everything that only needs to be done once. Here are some examples of things you might want to do:

• Assign values to variables
• Fill arrays with initial data
• Ask OPL for information about the sort of machine the program's running on (e.g. getting the screen height with gHEIGHT here)
• Set up strings to point towards commonly-used folders (e.g. Path$="\System\Apps\RMREvent\" here). This saves a lot of typing later on and also (again) means that you can change the program's name and folder structure easily in one single place.
• Create any scratch or data folders needed (e.g. TRAP MKDIR Data$ here. Note that the TRAP command is just there to ensure that if the folder already exists the program carries on rather than stopping with an error)
• Load any settings from your program's 'INI' file (e.g. the call to Load_INI_File: here)
• Set up the labels and icons on your toolbar (e.g. the call to Setup_Toolbar: and the TBarButt: calls here - we'll go into more detail with these soon)
• Load up any commonly-used graphics into OPL 'drawables' (e.g. all the gLOADBIT lines here - each drawable can be thought of as a bitmap held in memory and accessed through a specific name, e.g. FindId&). Note that you wouldn't load lots of full-screen graphics here as that would be quite wasteful of precious memory. The tiny button and interface icons used in RMREvent are fine, though.
• Set up your program's graphic window sizes (e.g. MainScn% etc here). Note that you will usually want to relate the window sizes defined to the actual physical screen dimensions (e.g. the use of Screenwidth% and Screenheight% here)
• Set up the initial contents of your graphics windows (e.g. the calls to Setup_Scroll: and Instructions: here)

You may be wondering, by the way, why the program name and version were defined separately and not bundled in with the other Init: stuff. The answer is that the program will often be changed in a hurry (making a quick change to the program, impatient to get it released etc) and it's vital to make sure that the version number isn't overlooked. Putting it at the top of the main code is a nice high-profile location.

Having set all the above up, the main screen of the program will be fully 'populated' with text, window frames, icons and buttons:

Don't worry that I've skimped over the exact details of setting up the toolbar and handling the graphics drawables, as we'll come to those in much more detail in the near future. For now I want to rush on to the most important bit of the entire program, where we start responding to things the user does (keystrokes, pen taps etc) and this will be the subject of the next lesson.