Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File15.11.3.1  Who is the viewer?                                      TOS

First, an application should determine if there is a viewer that the 
user prefers. It does this by (in this order) looking for an 
environmental variable called 'View', looking for a cookie in the 
cookie jar called 'View', and then looking for an environmental 
variable called 'SHSHOW' (which is used by the MultiTOS desktop, too). 
All these names are case-sensitive.

The value of each one of these variables is the full pathname of the 
viewer.

The programmer can determine if one of the viewers is in memory (as a 
desk accessory, usually, but it is possible for the viewer to be an 
application under a multitasking operating system) using the appl_find 
system call.

To use the appl_find system call, the path and the extension have to 
be removed from the name of the viewer and must be padded with spaces 
to a length of eight characters. If this is not done, the appl_find 
call will fail. It should be noted that appl_find is case-sensitive, 
so normally the value MUST be all upper case. It would not be wise to 
convert the name to upper case, however, as case-sensitive file 
systems may be used under MiNT or MagiC.

If the viewer has not yet sent its XAcc-identification (the ACC_ID 
message), the application does this now. This may be the case if the 
main application does not support the XAcc protocol.

If no viewer is found, the application should check the extended name 
(introduced in version two of the XAcc protocol) of all applications 
and accessories that have sent XAcc-identification messages for the 
string '2View' (this is the application type 'viewer') or the string 
'NView' (this is the generic type 'viewer'). If either of these 
strings is found, then the application/accessory in question supports 
the View protocol and may be used as a viewer. As in the case of the 
environment variables, the case of '2View' and 'NView' is significant.

If there is no viewer in memory but one of these environmental 
variables (or the cookie) was found, the application can try to load 
the viewer itself (using the pathname given in the variable). Please 
note that wildcards may be used in the extension of the viewer (a 
view-accessory could be named 'XXX.ACC' or 'XXX.ACX'). If the 'View' 
environmental variable was found, the viewer may be started as an 
accessory as well using Chameleon or MultiTOS. As a consequence of 
this, the viewer specified in the 'View' environmental variable must 
be able to run as both an application or an accessory. If the viewer 
cannot run as an accessory, it should be specified using the 'SHSHOW' 
environmental variable.

Normally the user should use one of the enironmental variables ('View' 
or 'SHSHOW'). These should be placed in the desktop environment, as 
all applications started by the desktop will inherit its environment. 
This can be done with special programs (ENVIRON.PRG, JCNBOOT.PRG) or, 
if MiNT is installed, by placing the following line in MINT.CNF:

setenv View C:\GEM_VIEW\GEMVIEW.APP

and/or

setenv SHSHOW C:\GEM_VIEW\GEMSHOW.PRG

Using MagiC the environment can be set by putting a '#_ENV' - line in 
the MAGX.INF file, like the following:

#_ENVView=F:\SHOW_IMG\SHOW_IMG.PRG

The cookie should no longer be used.