Using and Installing OPX's - Some Notes


OPX's are a mechanism for developers to extend the OPL language built into every Psion Series 5 (And GeoFox One) with new features that Psion did not initially provide. Authors use them to access more sophisticated features in the built in database, write to Agenda files and many others. They offer several advantages - they are easy to use (they work just like built in OPL commands) and relatively straightforward to create. They can also be shared among applications, saving users disk space and authors time - by re-using already debugged code.

There lies a problem though - what if two (or more) versions of an OPX exist and each application uses a different one? Since only one copy of the OPX can be installed on your Psion, how can you decide which one to use?

The answer lies in giving each OPX a version number, and letting the OPL runtime on the Psion check the correct version of the OPX is available before running an application. If the version is the same as or higher than the one the programmer used when writing the program then everything is fine. So where is the problem? What if Joe Bloggs writes ApplicationOne, which uses Funny.OPX version 1.2 (Funny.OPX lets him play a sound of laughter). Then John Smith writes ApplicationTwo some months later after Funny.OPX version 2.5 has been released (Two different laughs are available...). If you copy ApplicationTwo (and Funny.OPX) to your Psion and only then discover ApplicationOne on the web you will probably copy Funny.OPX version 1.2 over the version 2.5 that came with ApplicationTwo. Now when you run ApplicationTwo OPL checks Funny.OPX's version and won't let ApplicationTwo run, since the OPX version is too low. You see a dialog before the application starts that tells you that Funny.OPX is the incorrect version, and when you tap 'continue' the application stops, without even running.

If only you had installed ApplicationOne and then ApplicationTwo, all would be fine - since Funny.OPX version 2.5 is fully compatible with 1.2! Unfortunately there is no way for you to tell by looking at the OPX file what version it is. The solution is to put the OPX inside a sis file (like the message suite) that also contains the version number. Then if you try and install 1.2 over 2.5 nothing will happen, since EPOC Install (PsiWin 1.1 or the Add Remove Control Panel) prevents you from 'downgrading' a file without first uninstalling the newer version.

So as a User what should I do?

If you install an application which uses an OPX you already have, and it asks you to copy the OPX to \system\OPX, you should keep a copy of the current one you have. Then, if you find an application that stops working you can restore the backup of the OPX you kept - since it must be a higher version than the one you just installed. Note that you should always have a version of the OPX that works with all applications using it, since the highest version number will work with applications expecting older versions. Then pester the author to put the OPX's in sis files, so you don't have to ever worry - you always try to install the sis file, and EPOC Install tells you whether you need to or not.

And as a Developer what can I do?

Find out if the OPX you are planning to use is available in more than one version (as of this writing I don't believe this is true of any OPX). If it is, or might be in the future, insist on a version of the OPX wrapped in an sis file. This makes sure that your application won't break a program written in the future with a newer version of the OPX by accidentally copying over the old one. If you write OPX's you should always insist that it is distributed in a sis file (the rest of the application need not be). Note that you can put one sis file in another as a 'sub-install' so people will never need to take your OPX out of the sis file.


If a you have to copy OPX's to \system\OPX yourself, there is a risk that you will copy an old version over a new version and stop some applications from running. If OPX authors use EPOC Install (sis files) to distribute their OPX's the problem goes away because EPOC Install won't copy old versions over new versions. In the meantime those OPX's already available need to be installed with care if all applications are to continue running.

This page © John McAleely, July 2001