The following is a summarised version of comments made on CIX by Martin

Budden, (Software Engineer at Psion).  I'm posting here with his

agreement.



Cheers,

Chris Hennings



======================================================================

I've just had a look at Artworks and it has prompted me to make a few

general comments about writing OPL programs.



There are two types of files that a program can use: the files the

program actually manipulates (I'll call these its data files) (eg

the .DBF file used by the database), and the files the program needs

to run (I'll call these its program files) (eg any bitmaps it needs to

load, or any .OPOs that it loads using LOADM).  People seem to have

adopted various solutions to the problem of where to put these files,

I thought I'd offer some 'official' guidance.



The locations of an OPA's data files is determined by the PATH

keyword in the APP ... ENDA structure.  Artworks has chosen

\OPD\ARTW.  This is a reasonable choice, however we feel that if you

consider your application reasonably serious then you are justified

in creating your own directory off the root, so \ART, \ARTW, or

\ARTWORKS would be equally good, if not preferable choices.  We tend

to use 3 character directory names at Psion, but this is just house

style.  Use your judgement, if you are writing a small utility OPA

then it is better to use a directory off \OPD.



If your OPA creates any data files (besides the ones that are

shown under the icon) then you should give the user some way of

specifying which drive should be used for these files.  It is annoying

to the user if they are always created on M:, since this uses memory

that they may need for running applications (especially true if they

have memory-hungary applications eg the Spreadsheet).



An OPA's program files should NOT be stored in the same place as its

data files: THE USER SHOULD BE ABLE TO DELETE ALL THE FILES IN A

PROGRAM'S DATA DIRECTORY AT ANY TIME.  So where should you put the

program files?  In a directory of the same name as the OPA - this is

the standard that we have adopted at Psion for any APPs that are

released on SSDs (eg Chess).  An example will make this clearer.

Artworks requires a number of .PIC files to run (eg its title screen),

these should be placed in \APP\ARTWORKS, eg



    \APP\ARTWORKS\ARTTITLE.PIC

    \APP\ARTWORKS\ARTWORKI.PIC



etc, since ARTWORKS.OPA itself resides in \APP\ARTWORKS.OPA.  How do

you do this?  Again an example should make things clear:



PROC loadbt%:(name$)

    LOCAL file$(128),off%(6)

    file$ = PARSE$("",CMD$(1),off%())

    file$ = LEFT$(file$,off%(5)-1) + "\" + name$

    RETURN gLOADBIT(file$)

ENDP



so loadbt%:("ARTTITLE.PIC") will eventually call



    gLOADBIT("LOC::A:\APP\ARTWORKS\ARTTITLE.PIC")



(presuming the pack containing Artworks is in drive A).



CMD$(1) is used to get the full path used to start running artworks,

and PARSE$ is used to find the position of the .OPA extension which

is then replaced with "\" + name$.



A similar approach should be used when loading .OPOs with LOADM, or

indeed loading any type of file.



If the above approach is adopted then the user also has the

flexibility of changing the OPA's (or OPO's) directory.  For example

I have created a GAMES.ALS which runs any .OPOs in the \GAMES

directory, I have placed Minesweeper in this directory.  So

chennings, how about adopting the above convention for Minesweeper?



The above is written in the spirit of constructive criticism, I hope

I have not given the impression that I am knocking Artworks (or

Minesweeper).



======================================================================

If a program is a multi-file app (ie type 2 to type 4) then you have

no choice, it must be distributed as an OPA, since there is no way of

getting the file name onto the command line.



If a program is a 'no file' or 'one file' app (ie type 0 or type 1) then

you have the choice OPO or OPA.  Actually you can cheat: distibute

the program as an OPA.  This means the user can install it if they

wish.  However they can also rename it to *.OPO and copy it to \OPO

and it can then be launched from the OPL bubble.  So for instance you

could make Mines an OPA and then the user could put it where they

wished.



If programer's follow the PARSEing rules I outlined above then

should be able to rename their OPAs and copy them to different

directories with no ill effect.