Specifications

SERIES 3/3A PROGRAMMING GUIDE
2-4
Applications which are intended to be capable of being run on either mono- or multi-lingual Series 3s
should adopt the multi-lingual form of
.ms
file, and simply accept that the public name will be incorrect
on mono-lingual machines.
For multi-lingual machines, the System Screen uses the following rules to decide what the public name of
the application should be:
•
the current language number is obtained by a call to
p_getlanguage
•
if this matches any language for which a public name is explicitly defined in the shell data, that
public name is used
•
otherwise, the default public name is used (as given on the first line of the
.ms
file).
For the sake of minimising the size of a multi-lingual
.shd
file as much as possible, it is evidently possible
to omit any lines such as
01Data
which merely define the public name for some language to be what it would have been in any case, were
this line omitted (in view of the contents of the
first
line of the
.ms
file).
Pure file list applications
If an application (
Utils
, say) has type
5
, and the user presses
ENTER
when the highlight is over some file
Xyz.abc
in the file list for that application, the System Screen makes no attempt to run the application
Utils
. Rather, it assumes that
Xyz.abc
is itself a program, and attempts to run that. In other words,
instead of executing
Utils
and passing the filename
Xyz.abc
as part of the command line, it executes
Xyz.abc
(without any command line being passed).
For example, the
.ms
file for the built-in "application"
RunImg
is as follows:
RunImg.IMG
\IMG\
8005
This means that the file list for
RunImg
lists
.img
files from
\IMG\
top-level directories - each of which are
program files.
Note that unless the utility programs cooperate in some limited way, when run they will be listed (in bold)
under the
RunImg
icon, rather than under any other pure file list icon. This is explained in the section
below on the Epoc reserved static
DatProcessNamePtr
.
In practice, the simplest way to create another pure file list application is probably to use the technique of
aliasing, as discussed immediately below, to alias
RunImg
.
Aliasing applications
Some file-based applications may end up with large file lists. It may be desirable to separate a file list into
two or more separate lists, for example (for the
Word
application) all correspondence going in one file list,
all poetry in another, and so on. These file lists could be distinguished, on the System Screen, by having
distinct icons, and different application buttons could be used to cycle round running instances of these
tasks.
Going further, it may be desirable for the
behaviour
of the application to alter, depending on which type
of file is open. For example, the behaviour of the built-in text editor is different for
.wrd
files (when the
application is seen as
Word
) from
.opl
files (when the application is seen as
Prog
).
The concept of
aliasing
an application is designed to meet these requirements. For each required new file
list, an
alias
file (
.als
file) should be installed in the System Screen. In practice the user can do this on the
Series 3a using the "Create new list" item from the "Special" menu (try it out ...).
Broadly speaking, the contents of a
.als
file match those of a
.shd
file: the public name, default extension,
and default directory are all defined, as well as the application type number. However, the
.als
file goes
beyond the
.shd
file in that it also specifies:
•
the name of the application that is being aliased
•
(optionally) some
alias info
that the System Screen should pass to the application when it is run,
via the command line, to configure its behaviour in some special way.