Specifications

2 COMMUNICATING WITH THE SYSTEM SCREEN
2-5
Creating .als files
An
.als
file is produced from a
.ma
file and a
.pic
file by running the tool
makeals
. The three files all
have the same root name (ie disregarding the extensions). For example, the command
makeals letter
produces the file
letter.als
from
letter.ma
and
letter.pic
.
The
.pic
file is the icon to use. The process of creating
.pic
files is discussed in the previous chapter.
The
.ma
file is a source file similar in format to a
.ms
file. For example, the contents of a file
letter.ma
could be:
Letter.let
\WRD\LET\
3
Word
in which there is a fifth line which is blank (
makeals
will give an error if the fifth line is omitted
altogether).
Just as there are multi-lingual forms of
.ms
files, there are also multi-lingual forms of
.ma
files. However,
in practice these are of limited use, for technical reasons. This is discussed in its own section (which the
majority of readers can skip) at the end of this chapter.
The first three lines of a
.ma
file correspond
exactly
to those of a
.ms
file. The fourth file is the
public
name of the application to alias
. The fifth line gives the alias info, which is a zero-terminated string of
up to eight characters.
In most cases, the application type will be the same for the alias file as for the application being aliased.
However, the public name, the default extension, and the default directory are all commonly varied.
Note that the public name of an alias must differ from that of the application it is aliasing. Otherwise,
seeking to install the alias in the System Screen will have no effect (it is not possible to have two different
file lists, each with the same public name).
Incidentally, no check is made, at the time of installing an alias file, that the application it aliases is itself
currently installed. This check is only made when an instance of the alias is to be started.
Active aliasing and passive aliasing
In theory, all applications are capable of being aliased, without them needing to make any conscious
provision for this possibility. This is known as
passive
aliasing.
Other applications pay explicit attention to any alias info that may be passed to them on their command
lines, and adjust their behaviour according to the contents of this info. This is known as
active
aliasing.
An example of active aliasing is that of the built-in text editor, as described in the following section. This
is the only one of the applications built into the Series 3 and Series 3a that supports active aliasing.
Any other program that supports active aliasing is free to interpret alias info passed to it in any way that it
wishes. There is no obligation to mimic the detailed rules obeyed by the text editor.
Active aliasing in the built-in text editor
If the alias info is a null string, the text editor enters
Word
mode, with multi-level outline facilities, styles
and emphases, and so on.
Note that it is not unreasonable for an alias to define null alias info. This allows the creation of aliases of
the text editor that behave in exactly the same way as the built-in Word application, but differ from each
other in terms of their default extensions, default directories, and/or public names.
If there is any non-null alias info, the text editor enters one of a number of other modes, with the mode
depending on the first character of the alias info. Some of these modes are not available on Series 3
machines. At the time of writing, the allowed first characters and the corresponding modes are:
O
S
$
/
OPL program editor
Comms script program editor
Plain text editor (not Series 3)
Word processor with custom template (not Series 3)