Specifications

2 COMMUNICATING WITH THE SYSTEM SCREEN
2-13
In either case, the initial event prompts the application to call
wGetCommand
, to obtain the so-called
new
command line
giving more details about the event.
Contents of the new command line for System Screen messages
The parameter passed to
wGetCommand
must be the address of a buffer having at least
P_FNAMESIZE
(
128
)
bytes. The new command line is written into this buffer.
The first byte of the new command line will be one of
'X'
,
'O'
, or
'C'
:
'X'
means the command is a
Shutdown
message
'O'
means the command is a
Switchfiles
message, with a specified file to be opened
'C'
means the command is a
Switchfiles
message, with a specified file to be created.
In the case of
Switchfiles
messages, the remainder of the new command line gives the full pathname of the
file to open or create.
An example of code that responds to notification of a message from the System Screen is as follows:
LOCAL_C VOID ProcessSystemCommand(VOID)
{
UBYTE buf[P_FNAMESIZE];
wGetCommand(&buf[0]);
if (buf[0]=='X')
ExitApplication();
SaveIfChanged();
if (buf[0]=='C')
CreateNewFile(&buf[1]) /* remainder of message is ZTS of file to create */
else /* buf[0]=='O' */
OpenExistingFile(&buf[1]); /* remainder of message is ZTS of file to open */
}
Other possible types of messages
At the time of writing, the command byte of new command lines (as read by
wGetCommand
) is restricted to
one of the three values
'X'
,
'O'
, or
'C'
. It is possible, however, that some future application might send
messages to other applications having different command bytes.
These messages would be sent by means of the
wSendCommand
function, as described in the
Window Server
Reference
manual. (Note that these messages are
not
the same thing as IPC (inter-process
communication) messages; nor are they the same as object-oriented messages.)
In order to be future proof, an application should arguably test explicitly for all expected values of the
command byte, and should ignore values other than those expected. The above code fragment would
therefore need to be modified.
Multi-lingual aliasing of Word.app
This section can be omitted by all readers, except those who wish to write a multi-lingual alias of
Word.app
.
The reason why
.als
files as created by
makeals.exe
cannot be used in this case is that these files have to
contain the public name of the application being aliased. However, the public name of
Word.app
can vary
from language to language, and there is no facility to track this within an ordinary
.als
file.
To surmount this problem, the
.als
file can be re-written
as a program
.