Specifications

SERIES 3/3A PROGRAMMING GUIDE
1-4
An example of code that attempts to locate a resource file in the second add-file slot of a
.app
file is as
follows:
GLDEF INT rscfile_rs_init(PR_RSCFILE *self,TEXT *name)
{
ImgHeader head;
/* self->rscfile.offset is zero by default */
f_open(&self->rscfile.pcb,name,P_FRANDOM|P_FSTREAM|P_FSHARE);
if (p_read(self->rscfile.pcb,&head,sizeof(head))==sizeof(head))
{
if (!p_scmp(&head.Signature[0],"ImageFileType**"))
{ /* we have a .img file */
if (!(self->rscfile.offset=head.Add[1].offset))
p_leave(E_FILE_INVALID);
}
...
}
....
}
Multi-lingual applications
The topic of multi-lingual applications is discussed in general terms in the course of the
Resource Files
chapter of the
Additional System Information
manual.
There are some issues about the set of possible command hot-keys ("menu accelerators"), however, that
are particular to the Series 3.
The set of possible accelerators varies from language to language on account of the keyboard changing.
All languages must, however, support the 26 accelerators 'a' through 'z', together with four more.
These additional accelerators are '+', '-', '*', and '/' in most languages. The only exceptions so far are
French and Spanish (and Belgian, which uses the French keyboard):
•
French replaces '/' with '?'
•
Spanish replaces '*' with '>' and '/' with 'ñ'.
Applications which fail to take account of these changes when they are translated into another language
will find they end up carrying a "lame" accelerator: the accelerator is displayed on the menu, but there is
no way for the user to press the required key combination.
Environment variables on the Series 3
Environment variables can be a powerful programming resource whilst being, at the same time,
potentially
anti-social
.
There are two aspects to this:
•
environment variables consume space in a special RAM segment devoted to them - the more
environment variables are created (and the larger these are), the greater the chance becomes of
other applications failing to work properly - on account of not being able to create
their
environment variables.
• name clashes
are possible - data stored in an environment variable by one application may get
obliterated by another application storing different data to an identically named variable.
With regard to the first problem, all that can be said is that due caution should be observed. Otherwise,
your application may earn itself a bad name.
With regard to the second problem, what is evidently required is some kind of
naming convention
.
For a full discussion of environment variables see the paragraphs preceding
p_getenv
in the
Plib
Reference
manual.