home *** CD-ROM | disk | FTP | other *** search
- The PopUp system is supplied as an application (known as the PopUp Server)
- which supplies the actual PopUp windows, and a relocatable module (the
- PopUp Manager) which provides a simple but powerful interface to PopUps.
-
- In this documentation, 'client task' refers to any task/application that
- is using the PopUp manager to provide windows such as ProgInfo, SaveAs,
- etc.
-
- The PopUpManager module supplies two SWI calls for the creation and
- removal of PopUps. However, before describing them, I will detail the
- fundamental data structure used by the PopUp system...
-
-
- Application parameter block
- ===========================
-
- This block is supplied to the PopUp_Open SWI by the client task.
- The block specifies all the necessary information about what PopUp
- is desired, and how it should appear.
-
- The block is divided into 2 portions.
- The first 24 bytes are filled in by the client to indicate which PopUp
- is desired, and where/how to open it.
- The remainder of the block is set aside for PopUp-specific data -
- definitions of the available PopUps and the data they expect can be found
- in the document '4 PopUps'
-
- The header is thus defined as follows:
- block
- +00 0/CR terminated string identifying PopUp (12 chars incl. terminator)
- Note that the case of this string is unimportant
- e.g. "ProgInfo"
- +12 (word) OS-coordinate X position for PopUp to appear
- +16 (word) OS-coordinate Y position for PopUp to appear
-
- +20 (byte) Application flag byte (see below)
- +21 (byte) Reserved - must be 0
- +22 (byte) Reserved - must be 0
- +23 (byte) Reserved - must be 0
-
- (+24 onwards then contains the PopUp-specific data)
-
- The block is defined as 220 bytes long (this is so that it will fit neatly
- into a Wimp message).
-
-
- Application flag byte
- =====================
-
- This byte contains values requesting special service from the application.
- Currently, the defined flags bits are:
- bit value name meaning if set/meaning if clear
- 0 &01 IsLeaf a MENU PopUp is a menu leaf/
- a MENU PopUp is a standalone 'submenu' dialogue.
- 1 &02 IsStatic the PopUp should be STATIC (permanent)/
- the PopUp should be a MENU PopUp (non-permanent)
-
- Notes:
- All undefined bits should be zero.
- If the 'IsStatic' bit is set, the 'IsLeaf' bit is ignored.
- A standalone menu PopUp IS different from a static PopUp.
-
-
- PopUpManager SWI interface
- ==========================
-
- SWI "PopUp_Open" (&46D40)
- -------------------------
-
- Entry: R0 = pointer to application parameter block (see above)
-
- Exit: R0 = 0 for failure, else non-zero positive PopUp Handle
- All other regs preserved
-
- Description:
- This SWI instructs the PopUp Manager to open the PopUp described
- in the parameter block.
-
- After initiating the opening of the requested PopUp, this SWI will
- return a PopUp Handle if it succeeded.
-
- For reasons beyond our control, the window will be opened in the near
- future *after* the SWI has returned. (This means that it is feasible
- that you will get back a valid PopUpHandle but no window will
- eventuate! However, if your request is reasonable, this unhappy event
- should not occur often.)
-
- Due to a refusal on the part of the WIMP to allow a task (the PopUp
- Manager) to attach a window (the PopUp) to another task's menu,
- this call *may* generate a Message_PopUpRequest (see '3 Messages)
- in order to correctly open the PopUp - this is very simple to handle
- and is described in the next file.
-
- At a later stage, some PopUps may wish to return a new state (a new
- colour, font, etc) to you - this is also described later, in the
- section on Message_PopUpState.
-
- Apart from this, PopUp_Open is a 'set and forget' function. This
- especially applies to ProgInfo, which, as it supplies no return data,
- is entirely supported by the addition of one SWI call...
-
-
- ------------------------------------------------------------------------------
-
- SWI "PopUp_Close"
- Entry: R0 = PopUp handle as returned by PopUp_Open
-
- Exit: R0 is set to 0
- All other regs preserved
-
- Description:
- This SWI is used to close a PopUp.
- This should only be done in cases like (for example) the 'owning'
- window/document being closed, etc.
-
- Note that it is not necessary to use this call on a MENU PopUp, as
- it will go away automatically if you close the menu tree - thus
- a better way of closing menu PopUps is to SYS "Wimp_CreateMenu",,-1
-
- If your application quits unexpectedly it does not need to call
- PopUp_Close for any static PopUps which it is using - The PopUp Server
- automatically detects the passing of your task and will remove any
- PopUp windows which you 'own'.
-
-
-
- ==============================================================================
-
- The PopUpManager also supplies 2 more SWIs. These are only for internal
- communications between the server and manager, and MUST NOT be called by
- normal client applications. They are described below in case you feel the
- urge to write your own server application... (preferably a module!)
-
- SWI "PopUp_Register"
- Entry: R0 => PopUp id string (max 12 chars, including terminator)
- R1 = PopUp flag word
- R2 = Server's task handle
-
- Exit: R0 = 1 if you are now the registered server for this PopUp type,
- else R0 = 0
- All other regs preserved
-
- Description:
- This SWI call registers the given WIMP task as the server which will
- handle all requests for the given type of PopUp in the future.
- The SWI is therefore usually called several times by the typical server,
- to register it as providing several PopUp types.
-
- Note that if an existing server has already registered for a given
- PopUp type, your registration will supercede the old one (so your server
- will replace the other one for this PopUp type)
-
- The PopUp flag word is as follows:
- bit 0 (value &01): This PopUp type supports a MENU instantiation
- bit 1 (value &02): This PopUp type supports multiple STATIC
- instantiations
-
- Note that your server MUST support all types of instantiation that are
- defined in the "PopUps" document file, otherwise some programs which
- expect the default set of PopUp types may be unable to get the window
- that they desire...
-
- ------------------------------------------------------------------------------
-
- SWI "PopUp_Deregister"
- Entry: R0 => PopUp id string (max 12 chars, including terminator)
- R1 = (ignored)
- R2 = Server's task handle
-
- Exit: All registers preserved
-
- Description:
- This SWI de-registers the given server so that it is no longer expected
- to supply support for the given PopUp type. Note that if another server
- has taken over this PopUp type, this call has no effect at all.
-
- ------------------------------------------------------------------------------
-