How To Build Your Applications

Description

All the modules are in their own OPL files. To use them in your programs you have three choices:

1. Use a pre-processor and #include them into your source code.
2. Cut-and-paste into your source code.
3. Compile into an OPO module and LOADM/UNLOADM them into your application at runtime.

Personally, I would recommend the first option (as that is how I do it). I have organised the OPL source for each of the modules into a directory called \OPL\LIB and then refer to them as #include "\opl\lib\foo.opl" in my source. I know of three pre-processors that would work:

1. nOPL+ - An excellent shareware OPL pre-processor originally written by Andy Clarkson, now managed by Neuon. You can download it from: http://www.neuon.com/.
2. SLOWPP - A simple free pre-processor written by Andrew Lord. You can download it from his web page: http://members.tripod.com/~alord/psion/. Note that to access my module directory '\OPL\LIB' I had to modify it to accept longer include filenames. Edit the directv%: procedure and make the filnam$ variable longer (say 64 characters).
3. S3ATRAN - This is the PC-based OPL pre-processor written by Psion. It should be on your PsiWin CD (if you have it). It can also be downloaded from the Psion web site: http://www.psion.com/downloads/pc/

Please Note: None of the modules require a pre-processor in order to translate successfully. Where necessary, I have edited the code so it would translate using the standard built-in OPL Translator.

Examples

Using Preprocessors

Description

All the preprocessors allow you to include other source code files in your own. It is called the #include directive. Take a look at the following fragment of my DarkLight program:

APP DarkLght TYPE $1000 ICON "\PIC\DARKLGHT.PIC" ENDA PROC main: REM settings/preferences GLOBAL after%, aftert&, before%, beforet&, twlght%, chkep% REM housekeeping GLOBAL laston&, t1&, t2&, havehlp% GLOBAL origbl% :REM original HwGetBackLight setting mpStart%:( "init", "done" ) ENDP #include "\opl\lib\amsync.opl" #include "\opl\lib\iomngr.opl" #include "\opl\lib\findfil.opl" #include "\opl\lib\ini.opl" #include "\opl\lib\misc.opl" PROC init%:

As you can see, it starts off with the standard APP..ENDA block, followed by the starting procedure for the program. After that is a bunch of #include directives. These cause the preprocessors to insert the contents of those files into the source code that is sent to the OPL translator. Think of it as like a cut-and-paste of those files into your source code right then and there, except that there is only one central copy of the library source code.

Pros

• The library code exists in one spot where it can be easily updated.
• Updates to library code are automatically included the next time you rebuild your application.
• Your application is a single file with a known working library built-in. There is no chance of library updates breaking your users installed application.

Cons

• You need to use a special program (preprocessor) to build your application.
• Your application files (OPAs) are larger since they include the library procedures. This problem can be alleviated by using a program like OPA Cloak to remove redundant procedures.

Using Cut-and-Paste

Description

This is pretty simple. Highlight the source code in the OPL editor and then Bring it into your applications source code. Or do it using the clipboard in Windows. Translate. Presto!

Pros

• New bugs added to the library do not affect your application unless you redo the cut-and-paste.
• No preprocessing programs required.

Cons

• Bugs removed from the library are not removed from your application unless you redo the cut-and-paste.
• Cutting-and-pasting updates can be a real bummer.
• Some library modules are so large, they nearly exceed the ability of the Psion OPL editor to edit them. Copying the source into your own program may not leave much room.

Using OPO Modules

Description

This is also quite simple. Compile each library OPL source file into a OPO file. Your application can then use the LOADM/UNLOADM commands to access the library.

Pros

• Disk space requirements are reduced if more than one application uses the library.
• Runtime memory requirements may be lower if only the required modules are LOADM'd.
• No preprocessing programs required.

Cons

• Changes to the library may alter its operation. If applications are compiled against one version of the library and then the shared library OPOs are updated, applications may break.