home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
windows
/
b007_1
/
Docs
/
1%a0Intro
next >
Wrap
Text File
|
1993-05-25
|
5KB
|
118 lines
NOTE:
Please don't be decieved by the large amount of documentation supplied.
PopUps are EXTREMELY SIMPLE to use in your own applications.
The bulk of the documentation is the source for the PopUp server and info
on how to write new PopUps.
If you only want to use PopUps in your own programs, you need only read
about half of the first 4 files in this directory.
---
The PopUp Manager
=================
The PopUp manager is a RISC OS 2 and 3 compatible relocatable module which
manages server task(s) to provide an easily reconfiguarble set of windows
(PopUps) to desktop applications.
These windows include the following:
* Save-As
* Magnifier
* 16-colour (WIMP colour) picker
* 24-bit (TRUE colour) picker
* Program info window
* Font selector dialogue box
* Simple 'Print' dialogue as used by !Draw
* Multitasking problem report dialogue box
Possible ideas for future addition are:
+ Window to set an integer value within a certain range,
which offers a writable, slider icon, and 'bump' icons.
These windows are all things that should be standardised throughout all WIMP
programs. There are two types of PopUp:
STATIC PopUp
Dialogue windows which appear as 'permanent' entities, of which multiple
copies may be open at once. STATIC PopUps are usually opened from a menu
item such as "Font ...". And example of a static PopUp is FontSelect.
Note that if a PopUp provides more than one window (eg FontSelect uses
a base window plus 3 pane windows), it must be static.
MENU PopUp
Windows that appear either as a leaf of a menu (opened by following a
menu sublink arrow), or as a standalone 'submenu' window (opened by
clicking the relevant item in the parent menu instead of following
the arrow). Only one such PopUp can ever be open at any time - these
PopUps will disappear if another menu leaf is opened, if the operation
they control is selected (eg by pressing 'ok'), or if you click outside
the menu tree or hit escape.
The PopUp manager therefore provides all applications with a simple way of
producing these standard windows. It has several advantages over each
application handling its own windows on its own:
* Shared resources
All applications are smaller both from reduction in template and sprite
resources, but also from a reduction in the code needed for handling
these windows.
* System-wide consistency
If all applications move to use of PopUps, then a save-as box will be
*exactly* the same in ALL applicatons. This applies to the window layout,
the actions taken on clicks and keypresses, etc.
This also eliminates the possibility of different applications having
bugs in their window handling code that causes the window to act
differently (e.g. in all versions of Draw including RISC OS 3.10, you
can't type new numbers into the colour picker because it ignores you!)
In this case, only one bugfix should be needed to fix ALL such PopUps!
* Ease of replacement
Once an application uses the generic PopUp interface, new PopUps can be
produced to replace old ones, to give a new look, an extra button (eg a
'Cancel' button, etc), or add other facilities (select colour from HSV
picker as well as RGB picker, for example).
By simply double-clicking such an improved module, ALL applications
using PopUps will *instantly* be 'upgraded' seamlessly to use the new
format PopUp.
It also allows advanced users a more convenient way of customising their
applications than having to edit every application's templates file -
simply install your own custom PopUp set!
* Ease of use
Why does the WIMP provide a specialised window called a 'menu'? Apart
from all of the above reasons, it is to save the application programmer
some effort.
PopUps certainly make life easier for the programmer; PopUps are shown
by calling a single SWI call, and return values through a single Wimp
Message - significantly less work than loading templates, creating
windows, processing events, and deleting windows!
* Enforcement of style guide
If the OS makes these PopUps very easy to show, programmers are encouraged
to use the PopUps instead of doing all the work necessary to replace
them. This helps enforce the style guide, and gives programmers more
cause to think about something they are about to do:
If you want to add extra buttons to the save-as window, it means a fair
bit more work instead of using PopUp - is this really the best way to
handle it, or can the functions of those buttons be added elsewhere,
leaving the save as window as a consistent interface unit?
* Efficiency gains.
The Compiled C and hand-coded assembler modules which supply the PopUps
provide better efficiency than a BASIC program doing the same thing will,
probably enough to give a noticable response improvement in some places.
The PopUp manager has thus been designed to provide a generic interface to
these standard dialogues, mainly to make life easier for programmers, while
at the same time giving the aforementioned benefits.
More information on using PopUps in your own programs, and on writing your
own PopUps, is included in the other documents in this directory.