AES functions of MagiC 3,4,5
----------------------------

Andreas Kromke
27.4.95
English translation: Peter West, April 99.

- With compatibility activated, wind_create no longer hides any bits.

- WM_BACKDROPPED (Mag!X) is no longer sent, instead WM_BOTTOMED (AES 4.1) 
  is sent.
  All programs that create windows with an explicit backdrop element 
  according to the Mag!X convention unfortunately have to be altered for 
  MagiC 3.0, or respectively not altered if they support a (not present) 
  MultiTOS.

- AES controls the iconification of windows. One should note the following:
  - wind_get/set returns error codes if one attempts to iconify already 
    iconified windows etc. for a second time
  - The button lies at the right, so in an extreme case one can have 3 
    buttons at the right edge of the window. Perhaps it would be sensible 
    to banish the backdrop button to the left-hand side?
  - The algorithm for determining the position of the iconified window 
    works in a different way to that with MultiTOS. MagiC searches through 
    the current positions of already iconified windows and sets the new 
    window at a free position. A place is only free if the section at the 
    new position is empty.
  - The program Adresse 1.81 has problems and draws the icon diplaced, 
    possibly due to the thick MultiTOS window frame.
  - INTRFACE and GEMVIEW do not realise that the system supports 
    iconification. Is no appl_getinfo call made?
  - Iconification and deiconification of windows does not affect the 
    W_PREVXYWH - Grect.
  - wind_set(handle, WF_ICONIFY, -1, -1, -1, -1) always works and 
    establishes the icon position for itself.

- AES now supports 3D-objects according to the AES 4.0 standard. The types 
  "Background", "Activator" and "Indicator" are handled.
  Differences from AES 4.0:

  - In TOS 4.0 one can influence the behaviour of "Indicator" and 
    "Activator" as well as the colours with objc_sysvar, in MagiC one can 
    ask about the relevant data but not alter it. "Activator" is always 
    shown pressed for SELECTED, "Indicator" or "Background" change colour.
  - MagiC DEFINITIVELY DOES NOT SUPPORT 3D EFFECTS WHEN FEWER THAN 16 
    COLOURS ARE AVAILABLE SIMULTANEOUSLY. THE CORRESPONDING OBJECTS THEN 
    SIMPLY APPEAR "FLAT".
    appl_getinfo() for fewer than 16 colours or with explicitly 
    deactivated 3D objects returns the mesage: No 3D objects present.
  - One can request 3D effects for all object types, i.e. also for text 
    input fields, headings, group frames etc.
  - 3D objects do not get an additional frame and therefore do not change 
    in size. Depending on the frame width they stand out more and, if 
    appropriate, have an additional border and shadow.
    Headings should have a height of 1+3 in place of the previous 1+2, so 
    that everything looks tidy.
  - For 3D objects of the type G_USERDEF the 3D effects are not drawn by 
    the system, as happens with MultiTOS (?). This must be so because for 
    MagiC the 3D borders lie within the object and this may not be 
    overwritten.
  - So that the window borders did not have to be widened, characters 
    within buttons or boxchars are also output if the box is too small.
    The problem arose with window elements that had a height of (text+3)
    but actually needed at least (text+4).
  - The name field of the windows is not 3D. This can however be achieved 
    with the next version of the "wincolor.cpx" program by Martin Osieka.
    With that one can specify for each window element whether it should be 
    in 3D or not.
  - The "ornamental" borders for dialog boxes will be created only when an 
    Inner 2 pixels border and OUTLINED have been selected.

- The whole 3D support can be switched off by setting bit 1 of the flag 
  in magx.inf (bit 0 is responsible for the position of the logo). In use 
  one can then still switch over at any time with objc_sysvar().
- AES now supports objc_sysvar with the following sub-functions. The 
  parameters:

     #define LK3DIND      1
     #define LK3DACT      2
     #define INDBUTCOL    3
     #define ACTBUTCOL    4
     #define BACKGRCOL    5
     #define AD3DVALUE    6
     #define MX_ENABLE3D  10

  With MX_ENABLE3D one can deactivate in MagiC all 3D objects completely 
  and globally, i.e. also window frames, file selector, window border etc.
  Furthermore one can inquire whether 3D is being supported at the present 
  time. An attempt to activate 3D when fewer than 16 colours are available 
  results in an error message via objc_sysvar().
  AD3DVALUE always returns 0, as MagiC does not touch object sizes.
  The colours 8 (light grey) and 9 (dark grey) are used in all cases.
- objc_sysvar returns an error code when no 3D effects are activated.

- Even borderless objects are drawn in grey instead of white in 3D.

- F_TEXT and F_BOXTEXT only have a depressed border around the input field 
  when a border of at least 2 pixels Outside has been specified. With this 
  the external object dimensions are correct again.
- In the case of G_FBOXTEXT and 3D mode "Activator" the same type of 
  button will be drawn as under MultiTOS, so the input area will not be 
  emphasised.

- AES explicitly sends a redraw message for (de-)iconifying, even if the 
  size has not changed.

- The "cross button" always has an odd height, so as to avoid a "blob" 
  where the lines cross.

- Unnecessary window borders (at left and below) are omitted, as with
  AES 4.x. Although such windows look a bit spartan, they nevertheless 
  bring a few extra pixels of usable area.

- Bit 2 of the flag of MAGX.INF switches off the explicit backdrop button,
  which has the effect that a short click on the name field of an active 
  window triggers a backdrop. This is almost the procedure used by AES 4.x,
  except for the fact that MagiC itself still handles the backdrop if the 
  application is not in a position to do it.

- AES: Bit 3 of the flag switches off the new window title style. Bit 4 
  switches off 3D text for new window titles.

- Bit 5 of the flag (#_FLG) in MAGX.INF reverses the function of the Ctrl 
  key on the window sliders. This means that real-time scrolling can be 
  deactivated by setting the bit, pressing Ctrl activates it again.

- With 3D dialogs a suitable "fly corner" (or "asses ear") will be drawn.

- The ARGV procedure is supported. With this one can pass command lines of 
  any desired length, which also may contain spaces and all other possible 
  characters.
  For this $7f is entered as the length byte of the command line of the 
  basepage, the arguments (including argv[0] as a command, i.e. as program 
  file) are passed in the environment. For this purpose the environment 
  contains the following variables after all the others:

     "ARGV=something\0"
     "arg0\0"
     "arg1\0"
     ...
     "argn\0\0"

  The arguments therefore follow the variables of ARGV, are separated by 
  null-bytes and terminated by two null-bytes.
  Example programs for evaluation of ARGV are available from Atari. I 
  don't know, but doubt, if any program exists that evaluates ARGV.

  MultiTOS implements the procedure in the AES. One has to set the 
  parameter iscr, which is otherwise occupied in MagiC and called 
  "isover", to 1 and MultiTOS will then create the ARGV in the environment.

  MagiC implements ARGV on a lower level. The ARGV procedure is supported 
  in three ways already by Pexec:

     1. If the length byte of the command line is $7f, Pexec assumes that 
        the calling program supports ARGV and the environment has been 
        manipulated accordingly.
        Pexec therefore does not alter the environment.
     2. If the legth byte is $fe, MagiC expects the character string 
        "ARGV=" directly after this, followed by a null-byte and then a 
        list of paramters terminated by two null-bytes. By passing  
        "ARGV=NULL..." etc. one can also use the extended ARGV procedure, 
        which enables the passing of empty parameters.
        Pexec will delete any ARGV that may be present and enter the new 
        one into the environment. The command line consists only of $7f as 
        indicator that the parameters are to be found in the environment.
        This procedure is suitable if one is certain that the called 
        program masters the ARGV procedure.
     3. If the length byte is $ff, MagiC expects directly after it a list 
        of parameters separated by spaces and terminated by a null-byte
        (as is passed generally as a command line).
        Pexec will delete any ARGV that may be present, create from the 
        command line a list of arguments and enter these as ARGV into the 
        environment. argv[0] will be the program file path that was passed 
        to Pexec. Rubbish will result if this path is invalid, so one 
        should pass a sensible program name also for mode 5 (create 
        basepage). With mode 7 argv[0] is then simply called "NONAME"
        as no name has been passed here.
        The command line has $7f as a length byte, as an indicator for the 
        presence of ARGV. If the length of the command line is < 127, then 
        this is also copied to the basepage, otherwise the command line 
        consists only of $7f.
        This procedure is suitable if the calling program is not certain 
        that the called program understands ARGV.

  Why don't I just basically always create ARGV? Obvious! Because one can 
  guarantee that there are programs that stumble over ARGV. Let's just 
  assume that a parameter was called "VAR=value", then every program would 
  take that as an environment variable. If new variables are appended, 
  perhaps by a command processor, then these would be lost immediately if 
  they are placed after an "ARGV=".
- ARGV procedure altered. The character string "ARGV=blubber" must now be 
  passed, which makes the passing of empty parameters possible.

- shel_write has been extended as follows:

 1. If a character string that starts with $ff and is terminated by '\0' 
    is passed as a "tail", the actual length of the command line is 
    established by the AES and its whole length passed to DOS. The DOS 
    constructs from this an ARGV parameter in the environment (see above).
    If the command line is shorter than 127 bytes, it is passed via the 
    basepage and shel_read, otherwise it consists only of the byte $7f.
 2. If a character string starting with $fe is passed as a tail, the AES
    expects this to be followed by the string "ARGV=something" and a '\0' 
    separated and "\0\0" terminated list of parameters.
    This is passed complete to the DOS, which constructs an ARGV parameter
    from this (see above).
    If the command line is shorter than 127 bytes, it is passed via the 
    basepage and shel_read and with the null-bytes replaced by spaces, 
    otherwise it consists only of the byte $7f.
 3. Following the MultiTOS convention one can now pass extended 
    parameters. If bits in the high byte of the parameter "doex" are set, 
    then instead of "command" a pointer to a table of longwords is passed:

     tab[0]         is a pointer to "command"
     tab[1]         value for Psetlimit, supported from 25.9.95 onwards
     tab[2]         value for Prenice, will be ignored at present
     tab[3]         pointer to default directory, ignored at present
     tab[4]         pointer to the environment

    The default directory is set much simpler under MagiC, as the new 
    program inherits all paths on all drives from the calling program. 
    The important thing here is mainly the possibility to pre-set an 
    environment.

- wind_set(WF_UNICONIFY) altered, instead of the saved parameters the 
  passed parameters will be paid regard to.

- shel_find corrected for PATH variable without a closing '\'.

- MGFORMAT no longer uses Protobt to create the boot sector.
  For 720kB floppies an MSDOS-format with 730,112 free bytes is now 
  created.

- wind_get(WF_BOTTOM) corrected.

- wind_get(WF_TOP) hack for Tempus removed.
  Tempus CAN NOW LONGER RUN!!!!!!!! In case of problems contact Wilfried.

- appl_getinfo() returns to shel_write() the information:
  Only modes 0 and 1 present ("Nur Modi 0 und 1 vorhanden").
  Actually present are: 0/1/4/5/9/10

- AES: appl_getinfo() reports "objc_sysvar() not present" when the 3D
  objects are deactivated (e.g. in monochrome resolutions).

- appl_getinfo() returns:

* Table for sub-function 7
 DC.W	%0000000000000111	; 0: WDIALOG-library preent
						; 1: SCROLLBOX-library present
						; 2: FONTSEL-library present
 DC.W	0
 DC.W	0
 DC.W	0

- wind_set() with invalid mode returns 0.

- wind_get(WF_KIND) supported.

- The program XMEN_MGR (best placed in the APPS folder) installs the 
  following functions:

     menu_popup()
     menu_attach()
     menu_istart()
     menu_settings()

  appl_getinfo() returns a "1" for the corresponding sub-functions when
  XMEN_MGR is installed.
  Intelligently, menu_popup() has the same AES function number as
  menu_unregister(), and menu_attach() has the same as menu_click(). The 
  functions are differentiated by the type and number of passed 
  parameters.

- appl_find("?AGI") => 0 instead of previous (-1)

- At the special request of two individual gentlemen, who are always 
  referred to as a pair, the small cross button in 2D mode is no longer 
  drawn in XOR but in REPLACE mode.
  One should therefore take care that the background is white in 2D mode,
  otherwise there will be problems.

- MAGXDESK can iconify windows. "Iconify all" though is intentionally
  ignored.
  MAGXDESK 3 supportst iconification fully.

- MAGXDESK: AV_STARTPROG and VA_PROGSTART incorporated. One can start 
  installed files and programs. In the "single mode" case, the caller may 
  however receive the VA_PROGSTART message only after the called program 
  has terminated (depends on whether background DMA is active).

- MAGXDESK: AV_STARTED will be evaluated, i.e. the memory block that 
  belonged to this command line is released. This is a bit silly as the 
  block now belongs to the called application and no longer to Magxdesk,
  but extended AES messages should perhaps not be propagated as these do 
  not exist in MultiTOS. Long live the corpses!
  The correct way would be for the called program itself to release the 
  block. This is how MGCOPY works. The way that Magxdesk retains the block 
  also sours things because not every program sends the AV_STARTED message 
  and otherwise a heap of messages would pile up that would not be 
  released. In this way they are at least released automatically when the 
  called program terminates.

- ARGV parameters will be used always if the command line is too long for 
  the old method (i.e. more than 126 characters). If a passed filename 
  contains spaces, it is enclosed in quote marks.
  In MAGXDESK there are three methods to pass arguments, i.e. command 
  lines, to a program:

	a) By starting the program

	Long filenames are passed here simply with shel_write().
	This mechanism has long been integrated in MagiC. One sets 0xfe as 
	the command line length and just passes the character strings
		"ARGV=something"
		arg1
		arg2
		...
		"\0"
	after this. Each argument is terminated with '\0', two null-bytes 
	terminate the list.
	The called program receives an empty command line with length byte
	0x7f; this corresponds to the official standard.

	b) With a message (VA_START)

	Here no length bytes will be transferred, but only space-separated
	arguments of any desired total length.

	c) With Drag & Drop

	For this the same applies as for b).

- MAGXDESK: Filenames with spaces are enclosed in quote-marks. Hence there 
  is no need to differentiate between long and short (8+3) filenames for 
  Drag & Drop and VA_START. Very practical!

- MAGXDESK: When using the ARGV procedure, filenames containing spaces 
  are no longer enclosed in quote-marks.

- I have experimentally set the AES version number to 4.0. Unfortunately
  GEMVIEW still does not show an iconifier. A new problem child is 
  XCONTROL, which, though it allegedly understands AP_TERM, intentionally 
  ignores the message.
  SHUTDOWN therefore reports a timeout.

- Iconified windows no longer have a backdrop button. The size has been 
  adapted to match that in MultiTOS and has an overall width and height of 
  72 pixels.

- If the resolution is not suitable for displaying windows with a 3D 
  frame, then the width of the 3D frame will be reduced. Previously all 3D 
  buttons were empty.
  It is highly recommended to switch to 2D display in TT low resolution.

- For wind_set(WF_ICONIFY) one can pass {-1,-1,-1,-1} for the GRECT. In
  this case the icon position will be calculated. This also works in the 
  beta-version of MultiTOS, but there one has to close the window first.

- menu_register will not be executed and returns -1 when it has not been 
  executed by an ACC.

- Colour icons supported.

- G_F(BOX)TEXT with 3D flags "Indicator" or "Background" implemented for 
  small fonts. Up to now only a large font was possible. But who uses 
  input fields with a small font?
  If one does not wish to produce an input field then one should 
  definitely not set the 3D flag if the appearance should correspond to  
  that of a 2D object in "transparent" mode.
  This means: Keep away from 3D flags unless you know what you are doing!

- Internal menu manager extended. The extended MN_SELECTED format is now 
  also supported by the internal menu manager (appl_getinfo altered 
  correspondingly). One receives in buf[5,6] the menu tree (OBJECT *), 
  i.e. the tree passed to menu_bar(). The case that another tree was 
  selected, like the left menu in MutlitTOS, does not happen in MagiC so 
  far. In buf[7] one receives the parent of the selected menu entry, i.e. 
  the object number of the "dropped" box that contains the selected menu 
  entry.

- If colour icons can not be displayed due to an unsuppported screen 
  memory format, then monochrome icons will be displayed.
  If one doesn't want any text, one has to
  - either set the text width to 0 (better!)
  - or place the text in a position where it is covered by the icon.

- wind_set(WF_DCOLOR) has been extended as follows:

  W_FULLER:    For compatibility reasons with older versions this also 
               alters the iconifier and the backdrop button.
  W_SMALLER:   As in AES 4.1 one can modify the iconifier with this.
               Other objects will not be altered. So one has to first 
               alter the FULLER and then the ICONIFIER.
  W_BOTTOMER:  For the backdrop button. Only works in MagiC, not in 
               MultiTOS. Here too no other object will be affected.

- wind_set(WF_ICONIFY) with g = {-1,-1,-1,-1} places the window at the 
  next free position for iconified windows.
- AES:

	wind_set(-1, WF_TOP, apid);

  switches over the menu and desktop background to the application <apid>.
  If -1 is passed then this is the current application.
- AES: Via wind_set() it is now possible to set 3D flags for each 
  individual window element. The implementation has arisen following 
  discussions with Martin Osieka. Procedure:

     wind_set(0, WF_DCOLOR, elem, actcol, inactcol, flags3d);
     wind_get(0, WF_DCOLOR, &elem, &actcol, &inactcol, &flags3d);

  flags3d looks like the following:

     Bit 0:    "3D in foreground" effect
     Bit 1:    "3D in background" effect
     Bit 2:    "Selectable in foreground" effect
     Bit 3:    "Selectable in background" effect

     Bit 8+n:  Mask bit for bit n

  i.e. bits are only altered when the associated mask bit is set.

  Restrictions:

  MagiC 3 at present supports only bit 0, so for wind_get <flags3d> is 
  0x0100 or 0x0101 (i.e. only bit 0 is valid).
  This feature has not yet been implemented in appl_getinfo(). Planned is
  sub-function 11, bit 9.
  Extensions may follow when Wincolor by Martin is available for testing.
- wind_open() with g = {-1,-1,-1,-1} places the window at the next free 
  position for iconified windows.


EXTENSIONS since the first release version:
===========================================

From 15.4.95:

- Extended version of appl_write() introduced. If the ap_id of the target 
  application is -2, "msgbuf" points to the following structure (->MAGX.H):

     typedef struct {
          int  dst_apid;
          int  unique_flg;
          void *attached_mem;
          int  *msgbuf;
          } XAESMSG;

  Here <dst_apid> and <msgbuf> contain the usual message information.
  <unique_flg> specifies whether messages of the same kind (i.e. with 
  the same message type msgbuf[0]) should be overwritten by the new 
  message or not.
  If <attached_mem> != NULL, then it's used to specify a memory block 
  allocated with Malloc() that contains the extended message information.
  The length of this block is irrelevant and of no interest to the system, 
  so it could be passed as the first longword of the block or in 
  msgbuf[4,5], for instance. The system allocates the memory block to the 
  target application and passes on its address in msgbuf[6,7]. The calling 
  application must assume that msgbuf[6,7] are destroyed after a 
  appl_write() call. The system reserves the right to copy the contents of 
  the memory block elsewhere and to release the passed block. After the 
  appl_write() the caller MAY NO LONGER ACCESS THE BLOCK AND UNDER NO 
  CIRCUMSTANCES RELEASE IT !!!

  If appl_write() returns an error code then the block was not passed and 
  belongs, now as ever, to the calling application. An error arises if:

     a) The target application is invalid (does not exist or is frozen)
     b) The message buffer of the target application is full
     c) The target application is not a process (e.g. the SCRENMGR) and an
        "attached memory block" has been specified.

- appl_write() reacts from MagiC 4.50 on correctly with a return value 0 
  to the attempt to send messages with a negative length.
- Experimentally: The backdrop button may switch over the menu bar if 
  appropriate. This could still lead to problems if someone hadles the 
  backdrop message themselves, because then the menu bar would not be  
  switched over. But who would do that?
- Inactive menus may be drawn by setting the flag RBUTTON of object #0
  (for tear-off menus).
- AES: objc_draw() adapted to MultiTOS. A series of experiments has 
  established the following results:

 1. G_BOXTEXT OPAQUE 3D is converted to G_BOXTEXT TRANSPARENT 3D
 2. G_TEXT OPAQUE 3D is also converted to G_BOXTEXT TRANSPARENT 3D

  The stupid thing is that in case 2. the whole object is underlaid with a 
  grey box, not just the text string. What's more, these conversions are 
  actually completely unnecessary since one could use G_BOXTEXT from the 
  start. But people don't do this, which is why some objects under MagiC 
  did not appear as one wanted them to.
- AES: objc_draw() draws selected 3D objects that do not become dark grey 
  and that do not appear "depressed" with a black XOR box, as for 2D.
  MultiTOS does the same (if I didn't say this people would protest). 
  Affected: G_TEXT, G_IBOX and the MagiC group frame.
- Although 3D/FTEXT/OPAQUE is underlaid with a box (like BOXTEXT), it is
  now, as in MultiTOS, drawn without a border frame.
- AES: For shel_write() the mode with doex=7 incorporated (SHW_BROADCAST).
  Incredibly important, specially as every application in any case has a 
  workaround by means of appl_search()!
- AES: shel_write() with mode 8 results in error code 0 instead of 
  starting a program.
- AES: Specifying a Falcon resolution mode via shel_write() results in the 
  opening of the VDI device with device number 5 and specification of the 
  mode in ptsout[0] before calling v_opnwk().
- AES: shel_write mode doex = SHW_LOAD_ACC (3) implemened. Return value is
  the ap_id, or 0 if insufficient memory is available, the file does not 
  exist, or no application slot or menu entry is free any more.
- The extended shel_write() mode according to MutliTOS now also supports 
  the field for Psetlimit().
  For this the extended doex flags(SHW_XMD...), of which SHW_XMDLIMIT and 
  SHW_XMDENV are supported by MagiC, are defined in MAGX.H. The passed 
  structure is declared as XSHW_COMMAND.
- form_keybd: The keys Undo/Help/^Q are ignored when the object is 
  DISABLEd.
  

From 11.9.96:

- objc_edit() no longer uses a fixed buffer for a maximum of 80 characters 
  but instead creates a buffer on the stack for 256 characters.
- AES: With Ctrl-click on an ACC entry in the ACC menu one can remove an
  accessory.
- Window title: Lines can be switched on and off with the Wincolor 
  "Replace" flag. With window in foreground with Replace and background
  Transparent, one can suppress the lines for background windows.
- MGCOPY: When reading from drive A: or B: only a maximum of 32kB buffer 
  will be used.
- AES: There is new validation character 'm' (for tedinfo->te_valid). It 
  permits all characters that are valid for a long filename, i.e. all 
  characters apart from control characters ((ASCII < 32) and ':' and '\'.
  ':' may not be used due to the Macintosh file-system. Perhaps one should 
  also exclude '/' (because of UNIX paths)?
- AES: Keyboard operation of app-popups (as with WinCom):

   Hide others      Ctrl+Alt+','
   Unhide all       Ctrl+Alt+'<'
   Hide current     Ctrl+Alt+'-'
   Tidy up          Ctrl+Alt+ClrH

- AES: Since MagiC 2 there is the possibility to send messages via 
  appl_write() to the SCRENMGR (application #1) to carry out the 
  following actions (functions as with the MagiC popup):

	Tidy up  		(subcode SMC_TIDY_UP)
	Terminate  	(subcode SMC_TERMINATE)
	Activate  	(subcode SMC_SWITCH)
	Freeze    	(subcode SMC_FREEZE)
	Unfreeze		(subcode SMC_UNFREEZE)
	Unhide all     (subcode SMC_UNHIDEALL)
	Hide others    (subcode SMC_HIDEOTHERS)
	Hide      	(subcode SMC_HIDEACT)

  Binding (->MT_AES.H):

--------------------------------------

#define SM_M_SPECIAL     101                           /* MAG!X       */

#define SMC_TIDY_UP		0						/* MagiC 2	*/
#define SMC_TERMINATE	1						/* MagiC 2	*/
#define SMC_SWITCH		2						/* MagiC 2	*/
#define SMC_FREEZE		3						/* MagiC 2	*/
#define SMC_UNFREEZE	4						/* MagiC 2	*/
#define SMC_RES5		5						/* MagiC 2	*/
#define SMC_UNHIDEALL	6						/* MagiC 3.1	*/
#define SMC_HIDEOTHERS	7						/* MagiC 3.1	*/
#define SMC_HIDEACT		8						/* MagiC 3.1	*/

	int msg[8];

	msg[0] = SM_M_SPECIAL;	/* 101 */
	msg[1] = ap_id;	/* ap_id, with SMC_TIDY_UP and SMC_UNHIDEALL own */
	msg[2] = 0;		/* No overrun */
	msg[3] = 0;
	msg[4] = 'MA';
	msg[5] = 'GX';
	msg[6] = ..subcode..;
	msg[7] = 0;
	appl_write(msg, 16, 1);		/* apid #1 is the SCRENMGR */

-------------------------------------------

- AES: wind_set(-1, WF_TOP) gives keyboard control for the application to 
  which the menu belongs.
- Operation of the MagiC popup, from MagiC 4.03:
  Scrolling takes place automatically if the mouse cursor remains for a 
  while above the first or last scrollable object. One does not need to 
  press any mouse button, though, in contrast to the MultiTOS concept,
  this operation is also possible while the mouse button is held down. 
  At present the scrolling speed remains constant.
  As opposed to the MultiTOS concept, the scroll arrows are only displayed 
  if there is more to be found in the corresponding direction. Furthermore 
  the whole menu need not scroll, only a section. 
  Finally there is no need to build the complete object tree, but only the 
  visible object.
  The MagiC popup scrolls when more than 16 entries have to be displayed.
  With many simultaneously running applications, however, the screen 
  build-up of the program manager (Ctrl-Alt-Esc) will be destroyed.
  The number of tasks that can run simultaneously has been increased from 
  20 to 126 from Version 4.03 onwards.
- With scrollable editable fields, since MagiC 4.50 the cursor is set to 
  the end of the text only when this is completely visible. Otherwise the
  cursor is placed at the start of the text.
