
		 ZapButtons: multi-media extensions for Zap
		 ==========================================

Index
~~~~~
1. Features
2. Installation
3. Philosophy
4. Technical
5. Limitations
6. Contact
7. History


1.0 Features
============

This module provides a convenient veneer over some Zap command calls. It is
designed to enable other Zap modes to conveniently offer panes of tools and
buttons to the user. When these buttons are pressed, arbitrary sequences of
Zap commands may be executed.

The toolbars may normally be attached to any of the corners of windows
of the mode which is supporting them.  They may also be 'fleeting'.
This means that they will only appear on the document currently being
worked on.  These options are normally configurable on a per-window basis.

The button bars will normally sport their own window furniture, allowing
them to be dragged around, closed and sometimes different configurations of
buttons or button bar shapes may be toggled between.  The ability to drag the
button bar to a point adjacent to where the edited text lies can be useful
for minimising unnecessary repetitive actions.  The options to close and
toggle between different button bar configurations should help to minimise
window clutter.

Buttons are most useful to beginners, and when using commands which operate
on the currently selected region.  As the pointing device is often used for
selecting regions, buttons can help to minimise the number of swaps between
different input devices made while editing.

The button bars can also offer their own menus using the same configurable
menu structures as Zap uses.  This can be used to minimise the menu-
structure wading which can sometimes be required when configuring modes.

Between them, ZapHoTMeaL and ZapHTML between them provide many commands
which operate on the current selection and many of these are used in
ZapHoTMeaL's own button bar.

Originally it also proved to be convenient to add another feature which
other modes can benefit from from to ZapButtons - that of window wrapping.

Window wrapping was originally implemented in Acorn's !Edit application.
The implementation within ZapButtons was the first time it was available
within Zap, but it has now been added to Zap's Kernel, and has consequently
been removed from its location here.

ZapButtons also offers a very, very simple autosave facility to Zap.  This
saves all modified files, (completely overwriting the originals) at regular
intervals.  It relies on Darren Salt's SAVEALL command (in ZapDS, v0.29 and
later).

For details of how to install this command in a sensible location, please see
the 'Menus' file.  Hopefully this command will be completely replaced by a
proper central autosave feature at some point.

ZapButtons offers its own mode, with its own button bar.  This is a simple
variant on the text mode but with Smart cursors always turned on.

Although the author welcomes correspondence concerning this mode, he makes
no claim that it is bug-free and, it is not guaranteed to perform any
particular function.  It is to be used entirely at one's own risk.

This is Freeware, and may be distributed freely provided that all the files
remain unmodified.  If engaging in large-scale distribution, it is
requested that you contact the author before doing so to obtain his
permission to do this. This is mainly to allow him to supply the latest
version.


2.0 Installation
================

Copy the !Buttons aplication into the !Zap.Modules directory. Zap will then 
need to be restarted.

Note that many modes will normally have their buttons option turned off by
default. This can be reconfigured as required from the 'Options' in
Zap's icon bar menu.


3.0 Philosophy
==============

The author wrote the module mainly for use with his own ZapHoTMeaL module,
but provided a generic interface to it to allow its use by all parties
concerned.

The HoTMeaL mode needed buttons badly.  A number of HTML commands provided
acted on the current selection.  This means the immediately prior to
executing the command, the user will almost certainly be creating a selection
with the mouse pointer. The buttons should help minimise the number of times
it is necessary to swap between different input devices.

Not all modes are in desperate need of button bars.  New users will find
button bars most helpful - some of their advantages include the option to
sport descriptive labels and they can be tailored to offer the options most
relevant in a given mode. Button bars could help minimise the complications
of having different keymaps in different modes where these simply bind
appropriate commands to relevant keys.

Email mode now also supports ZapButtons, as does ZapBASIC.

Other modes where there are a number of relevant commands include Martin
Ebourne's.  However, most of the users here will be programmers: this
species of beast has been known to spurn button bars and always use
keyboard shortcuts...

The button bars are designed to be easy to support, very flexible, and easy
for the user to configure.

The module offers support for multiple button bars, allowing different
groups of buttons to be toggled between.  It also supports multiple button
bars on a single window - not especially useful, but there.

Fleeting button bars are supported.  One of the problems with button bars is
that they take up space which could otherwise be usefully taken up by
documents.  When multiple Zap windows are being viewed, this problem could
become acute.

Fleeting toolbars only appear on the document currently being worked on. If
another document is selected, then the toolbar of the first document is
temporarily hidden from view, and the second document's toolbar is displayed.

Fleeting button bars work well as a solution to the problem of space wastage
by button bars.  They have the advantage of providing additional visual
information to the user about where the input focus lies.  Their only
disadvantage seems to be that it can be distracting to have button bars
appearing and disappearing whenever a different window is given the input
focus.

From the perspective of other mode authors, to provide buttons support three
mode entry points need to be intercepted and a sprite file, template file
and script file of Zap commands to be executed need to be supplied by the
mode.  No other work is necessary for a minimal implementation.  Modes who
wish to offer more sophisticated options (this is recommended) may do so.


4.0 Technical
=============

4.1 Scripts
4.2 Templates
4.3 Menus
4.4 Mode authors
4.5 Calling ZapButtons

4.1 Scripts
~~~~~~~~~~~
The format of the command scripts files is as follows:

Sections begin with "<BUTTONSn>" where n is the number of the button bar
concerned in decimal.  "(BUTTONSn)" is also acceptable.

Each section consists of a series of entries, one for each icon in the
relevant button bar's template.  These are in the same order as the icons
are stored in the template file.

An entry begins with a series of lines of Zap commands.  These may be in the
form of a colon-separated list.

If a line is prefixed by a '%' then the window the button bar is attached
to is not given the input focus before the line of commands is executed
(this normally happens automatically).

If Zap doesn't have the input focus then the commands are normally executed
on the window the button bar is attached to, using the most recent cursor
position in the document for any insertions/deletions.  However this depends
to some extent on whether the commands involved require this information. If
they don't then there are circumstances when the commands may be issued on
other windows, (see E-Command for details of the circumstances) so only use
'%'s if you're sure you know what you're doing, and then with caution.

If there is a "#" on the line, then control is passed directly over to
the JRF_SCRIPTADDR command (assuming ZapJRF v1.20 of later is present).
This means that a number of scripting directives are directly available for
use within buttons scripts.  When the script terminates (when a #ScriptEnd
directive is encountered for example) then the entire buttons sequence
stops and no more commands are executed, even if there are more after the
end of the script.

Any lines prefixed by a '$' are not 'learned' by Zap.

If more than one prefix is present on a line, then any "%"s must precede any
"#"s or "$"s.

Lastly there is a section of interactive help.  This is is a line, or a
series of lines, each prefixed with a "|" character.  The first line has any
leading spaces stripped from it and is then fed to providers of interactive
help upon request.  Any such subsequent lines are taken to be comments.

Lastly, the section is terminated by a single "-" character on a blank line.

The examples given should illustrate this.  Note that script files are
currently quite sensitive to errors.

4.2 Templates
~~~~~~~~~~~~~
The templates *must* be named "buttons0" - "buttonsn" - lower case is
important.

The templates are currently suffering from minor restrictions in their size
and format (see problems).

4.3 Menus
~~~~~~~~~
The button bars can also offer their own menus using the same configurable
menu structures as Zap uses.  The format of the 'Menus' files used to
provide these is the same as the one used in Zap itself.  Some modes provide
only one menu file which they use for their mode menu and for the menu they
offer on their button bar.

When editing such 'Menus' files, note that any commands put onto it
will need to work from the icon-bar in the options menu - this means that
no commands which operate on the current window/file/cursor should be used.

In modes whch offer separate menus for their button bars and their
configuration menus, this issue will not arise.


4.4 Mode authors (technical)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Three mode entry points need to be intercepted.

These are: e_start, e_end and e_openwindow.

The e_start routine should pass ZapButtons pointers to the sprites file,
templates file, and command script to be used in the button bar, and some
flags.  There is a complication in that the routine should also try to load
ZapButtons if it is not already loaded, before attempting the call.

The e_end routine should execute the BUTTONS_DELETE Zap command.

The e_openwindow routine should pass all it arguments on to ZapButtons if
this is present.  There are minor complications in that the no buttons are
found on the window, the mode should investigate creating a new one.
The basemode's e_openwindow entry point should be called if ZapButtons
cannot be found.

Modes will also need to handle the ZapButtons configuration settings. This
is to allow button bar settings to be controlled by the owning mode.

As easy configuration by the user is a high priority, it is strongly
recommended that modes load the Templates, Sprites and Scripts files from
disc rather than storing them in their bodies.

In principle, modes may edit the sprites scripts and templates files
themselves during operation.  They may also directly access the WIMP window
the buttons are on, to inspect the state of any toggled icons, writables,
etc.

4.5 Calling ZapButtons
~~~~~~~~~~~~~~~~~~~~~~
There are three main entry points to ZapButtons which mode authors may need
to use.

Name	       Module offset
============================
Buttons_Open	 &00000024
Buttons_Redraw	 &00000028
Buttons_Misc	 &0000002C

  Buttons_Open
  ~~~~~~~~~~~~
    \E R0=reason code (and other registers may hold values dependent on it)
       R0=0  : Open a button bar.
	       R1 : Sprite area pointer (this should have its first word set
		      up by the mode to the size of the area as normal.
	       R2 : Templates pointer. (The templates file should be
		      permanently loaded into memory.  ZapButtons uses its
		      own routines to parse it).
	       R3 : Script pointer.  This is a pointer to a file of Zap
		    commands to be used.  This should be permanently loaded
		    in memory and all command strings ***MUST*** be
		    terminated with CHR$0 characters.  It is common practice
		    to load the file and then replace all &0A characters with
		    &00 ones.
	       R4 : Flags word.  See flags section for more information.
	       R5 : Menu pointer.  File format as for Zap's 'Menus' file.
		      If bit 7 of b_flags is set then a pointer to a Zap/WIMP
		      menu structure may be provided here.  However, note
		      that modes which use an existing e_menu-style menu
		      should not give a pointer to this.  Instead using the
		      MODEMENU command provided by ZapTMT is recommended.
		      To cooperate with this mechanism, modes which provide
		      separate mode and buttons menus can arrange things so
		      that if the 'Menus' file is missing or empty then this
		      word points to a zero word; in this case the mode's
		      normal mode menu will be generated in its place.
	       R6 : X and Y offsets for creating the button bar.  The Y
		      value is in the top 16 bits.  Values are in OS units
		      (not currently implemented: R6 should be set to 0).
	       R7 : 0/Address of handler.  To allow modes to save
		      information about the offset and current status of
		      button bars, modes can opt to be informed when these
		      change (not currently implemented: R7 should be set to
		      0).
	       R8 : Zap window block.
       Note that this command will check to see if there is an existing
       button bar on the window with the same 'specification' (i.e. Sprite
       area pointer, Templates pointer and Script pointer).  If this is the
       case, then it will not create a new window, but will open the
       existing one instead.  This behaviour is designed to make things
       easier for mode authors.
       
       This command should normally be called at the end of the e_start
       routine - after you have got the options sorted out - normally you
       will be handling the buttons options and won't know what parameters
       to send ZapButtons before these options are sorted out.

       R0=1  : Delete all button bars on a particular window.
	       R8/R9
	       * Important note * in e_start this should be called before
		 calling Buttons_Open with R0=0 - if this stage is neglected
		 then opening the same file twice will cause errors.
       R0=2  : Close all button bars on a particular window.
	       R8/R9
       R0=3  : Used internally to toggle panes between different
		 configurations.
	       R8/R9
    \X all registers preserved.

  Buttons_Redraw
  ~~~~~~~~~~~~~~
    \E as for e_openwindow, i.e...
       R0=0 => Just before calling Wimp_OpenWindow.
       R0=1 => Just after calling Wimp_OpenWindow.
       R0>1 => Reserved.
       R1 : Open block (as for Wimp_OpenWindow) (may have R1=R8).
       R2 : (byte 0) : &FF - window wrapping / &00-&FE - normal wrapping.
	    (byte 1) : &FF - Use R3 as address of custom e_clnoff routine.
	    (byte 2) : Minimum wrap width - this may usually be set to 0.
	    (byte 3) : &FF - Use R3 as address of custom e_clnphy routine
	    Please note that R2 is *NOW REDUNDANT*.
       R3 : (if byte 1 of R2 = &FF) address of custom e_clnoff routine
	    (rather than using the basemode's e_clnoff - *NOW REDUNDANT*)
       R4 : (if byte 3 of R2 = &FF) address of custom e_clnphy routine
	    (rather than using the basemode's e_clnphy - *NOW REDUNDANT*)
       R8 : Zap window block.
    \X R0 = Flags.  This returns a value to say whether there were any
	    button bars which needed redrawing.  If bit 0 is set then one has
	    been found.  If it is clear then there are no button bars to be
	    found, and it probably means that one needs to be created.
	    These circumstances arise when File->New View is selected.
	    Zap does not tell modes when a window on a file has been opened,
	    only when a file enters a mode - this means that this awkward
	    trapping of the e_openwindow routine has lost its neatness.
       ...all other registers preserved.

    ...modes should intercept e_openwindow, check that ZapButtons is loaded
    and then simply pass control over to it.  

  Buttons_Misc
  ~~~~~~~~~~~~
    \E R0=reason code (and other registers may hold values dependent on it)
       R0=0  : Close a particular button bar.
	       R11 = pointer to button block.
	  \X : All regs preserved.

       R0=1  : Open a particular button bar.
	       R11 = pointer to button block.
	  \X : All regs preserved.

       R0=2  : Call a given subroutine for each existing button bar.
	       R1 = pointer to routine.
	       The routine is passes a pointer to the button block in R11.
		 It should preserve R0-R12.
	       Note that R9 and R10 are preserved between calling this
		 routine and the service routine being called.  This should
		 allow you to pass pointers to your workspace across.

       R0=3  : Used to update the flags representing the position of any
		 button bars on a given window.  To be used when the user
		 attaches a button bar to a different corner of the window,
		 for example...
	    \E R7 = proposed new button flags:
		      bit 30 : Fleeting;
		      bit 29 : Top;
		      bit 28 : Left.
		    Other bits are currently ignored.  These should be set to
		      zero to avoid future problems...
	    \E R8 = window which might need updating.
	    \X R0 = 0 if no update has been performed.
		 != 0 you will then need to call the open window entry point
		    (which means setting up a block and calling
		    Buttons_Redraw) yourself to make sure the screen is
		    updated properly.

       R0=4  : Used to perform a crude update to the screen.
	    \E R8 = window to be updated.

       R0=5  : Used to redraw the screen in a detailed manner using the
		 TMT_UPDATEWINDOW command.
	    \E R8 = window to be updated.

       R0=6  : 'Read last Button click'.
		 Used to return the state of any mouse buttons which were
		 pressed to cause the execution of the current command
		 (or zero, if the command's execution was not caused by
		 the pressing of a button).
	    \X R0 = buttons pressed (b0=ADJUST, b1=MENU, b2=SELECT, etc.)

       R0=7  : 'Flush redraw cache'.
		 Forces any subsequent calls to Buttons_Redraw to reformat
		 the display.  Call this after changing the 'wrap type'.

If the window wrap option has changed state then calling Buttons_Misc with
R0 = 7, R0 = 4 and then R0 = 5 in that order should clean things up.

Button blocks
~~~~~~~~~~~~~
Each consists of 8 words as follows.

b_window   : Window *offset* of the window the button bar is attached to;
b_handle   : WIMP window handle of the button bar;
b_template : Pointer to the button bar's templates;
b_sprites  : Pointer to the button bar's sprite area;
b_script   : Pointer to the button bar's script file;
b_offsets  : X and Y offsets from the corner it is attached to;
b_flags	   : Button flags;
b_menu	   : Pointer to the button bar's menu file;

b_flags bits are as follows:
      0 : rsvd
      1 : Horizontal attachment:  0 = LHS,     1 = RHS;
      2 : Vertical attachment:	  0 = Top,     1 = Bottom;
      3 : Fleeting:		  0 = Static,  1 = Fleeting;
      4 : Sticky edges:		  0 = Normal,  1 = Sticky (not used yet).
      5 : Closed:		  0 = Open,    1 = Closed;
      6 : Permanently closed:	  0 = Open,    1 = Closed;
      7 : Zap/Wimp ptr in b_menu: 0 = Textual, 1 = Raw Zap/Wimp menu pointer.
   8-15 : Reserved...
  16-23 : Window handle fudge - contains the bottom 8 bits of the window
	  handle of the window the pane is attached to.  ZapButtons currently
	  uses this to identify windows in addition to the window offset.
	  When Zap tells modes when windows are being closed, then this will
	  no longer be required.
  24-31 : One byte representing the number of the currently displayed button
	    bar. Modes may allow configuration of this if they choose to do
	    so.

Note that some module offsets currently need to be called directly:
finding the address of the BUTTONS_REDRAW and BUTTONS_MISC command does not
appear to work completely reliably (Zap_FindCommand appears to corrupt
something used in some of the the calls?).  Doing this in an initialisation
routine is not always entirely practical as ZapButtons might not be loaded
then.


5.0 Problems and wishes
=======================

* ZapButtons' button bar may never be much use; see ZapHoTMeaL for a more
    serious implementation.  It is the author's intention that in the long
    term ZapButtons will stop providing its own mode at some point.
* Saving the position and type of the button bars has not been implemented.
* There are currently no alternative button bars supplied.
* The existing sprites are:
    * Designed for those who are space conscious;
    * Aesthetically suited to those who like their Zap backgrounds black.
  Not everyone fits into these categories. Hopefully more will be designed.
  If any third parties were to design any templates and sprites of reasonable
  quality, then the author would be happy to maintain a central archive of
  these.
* The command files are still quite sensitive to errors.  These tend to be of
    the nasty kind (hope to make less fragile).
* The templates which may be used are currently limited.  These should not
    have any title bars or indirected title data.  Also, non-indirected
    sprite-only icons may not work (hopefully to be fixed).
* The WIMP messages that carry interactive help are not currently made
    available to extension modes from within Zap.
* It would be a positive feature if commands which were 'tickable' when on
    menu entries could be selected/greyed out in a similar manner if they
    appeared on a button.  It is *possible* to implement this crudely
    at the moment for individual commands, but central support would be good.
* The window redraw in window wrap mode is currently implemented by messing
    around with the current selection.  This causes flicker when large areas
    of documents are selected - hopefully, this can be addressed centrally.
* When editing the end characters of a line with window wrap turned on, and
    with right indent set to a non-zero value, the window scrolls in a
    counter-intuitive manner.  The best way for the author to eliminate this
    problem is probably to put the window wrap code into the kernel.  At the
    moment, if it is found to be irritating, the feature can be disabled by
    editing the 'Right cursor indent (chars)' line in the keys file to the
    value of -1 (this is better than 0).
* On 'New view' (usually from the file menu) the new view has the default
    button bar for the mode rather than the same one as the parent window.
* There is no support for lo-res sprites yet.  Ideally the program should
    swap between using different templates/sprite files on mode changes when
    required.
* The supplied sprite style of many button bars is virtually unusable in 2-
    and 4-colour modes.  See Darren Salt's ZapEmail or ZapBASIC for a more
    sensible set of buttons from this perspective.


6.0 Contact
===========

Bug reports should be sent to bugs@zap.tartarus.org, requests for new features
to zap-features@zap.tartarus.org. There are a number of other mailing lists you
can subscribe to as well, for details see Zap's website at

                         http://zap.tartarus.org/

7.0 History
===========

v0.57 - (06-Jul-01)
      * Bugfix to Scripts loading code.

v0.56 - (27-Sep-99)
      * Fixes for Zap v1.45. (TMT_EVENT now named EVENT.)

v0.55 - (31-Nov-97)
      * Recoded for the current release of Zap.  Window wrap code all
        completely ripped out.

v0.54 - (16-Nov-97)
      * Recoded for the current release of Zap.  Window wrap code all
        completely ripped out.

v0.53 - (13-Sep-97)
      * Bugfix: Window wrap in BASIC mode sometimes failed to shift the
	screen correctly.

v0.52 - (04-May-97)
      * Interactive help messages are now processed by ZapButtons.  When Zap
	passes on interactive help requests, ZapButtons will be able to
	reply with relevant text.
      * ZapButtons will now use window-closing messages from Zap and messages
	about the location of the input focus (when these are available in
	future versions of Zap) to make sure its button bars open and close
	in a more responsive manner.

v0.51 - (30-Apr-97)
      * Window-wrapped windows no longer wobble stupidly while they are being
	resized, making it difficult to keep track of the position in the
	file.  Sorry this ever happened in the first place.

v0.50 - (17-Apr-97)
      * Fix of a pretty fundamental bug which caused the window-wrap code
	to fire when it shouldn't do so under a number of circumstances.

v0.49 - (16-Apr-97)
      * Fix of a fundamental bug which caused Zap to crash under some
	circumstances when clicking on the 'Buttons' options in menus.

v0.48 - (03-Apr-97)
      * Fix of a fundamental bug when copying to a window with window
	wrapping on - this now no-longer incorrectly sets the width to the
	size of the current window...

v0.47 - (19-Mar-97)
      * Yet another attempted fix for the toggle icon bug.  This fix is very
	kludgy, but would appear to completely cure the problem of the whole
	computer sometimes crashing when the toggle icon was toggled.

v0.46 - (19-Mar-97)
      * Buttons_Redraw now returns a flag in R0 to say whether it found any
	button bars to redraw.  If this is Zero, then the mode will probably
	need to create one.  This (and other changes) address a large number
	of problems with creating a new window on a mode by choosing the
	File->New view menu option.

v0.45 - (18-Mar-97)
      * Another attempted (and failed) fix for the toggle icon bug :-(
      * Allowed the "<BUTTONSn>" format.
      * Fixed bug involving changing mode and then toggling the buttons on
	from the mode menu.
      
v0.44 - (15-Mar-97)
      * Problems with AutoSave are looking to be terminal in the short-term.
      * Various problems with calling the BUTTONS_FLAGSTOGGLE command when
	not in Buttons mode resolved.

v0.43 - (14-Mar-97)
      * Redraw calls added to Buttons_Misc.

v0.42 - (12-Mar-97)
      * A kludgy fix for problem involving windows having an extra button bar
	attached to them if they are opened within miliseconds of another
	window with a button bar closing.  This means that button bars now
	rely on the window handle of a window remaining constant throughout 
	their lifespan.  The kludge will only be required while Zap does not
	inform modules directly when it is closing windows on files.

v0.41 - (11-Mar-97)
      * Auto-save now added and works properly from loading when it is put in
	to Zap's icon bar menu.
      * Addition of being able to specify a WIMP menu, to be attached to the
	button bar.

v0.40 - (10-Mar-97)
      * The menu file is now used for the mode menu as well as the button-
	bar menu.  Both of these now work properly.

v0.39 - (09-Mar-97)
      * Commands in script files may now have their terminating zeros
	attached by cooperating modes.
      * BUTTONS_FLAGSTOGGLE command documented and made to tick menu items.
      * Menu support improvements.

v0.38 - (09-Mar-97)
      * Menu code and 'Menus' files added.
      * The redraw optimisations in 0.36 were too severe; sometimes the
	window wasn't getting updated at all.  Hopefully this is now fixed.
      * Until now "Wimp_ForceRedraw" was being used to update the Zap's
	window directly.  Now "Wimp_UpdateWindow" is being called; this
	means that only the parts of the window that are uncovered are
	redrawn.

v0.37 - (08-Mar-97)
      * A number of commands have now been moved from ZapButtons into ZapTMT.

v0.36 - (08-Mar-97)
      * Until now, window wrap has been very slow when scrolling large
	documents by dragging their scroll bars.  This was because the code
	used to invalidate Zap's cache whenever it redrew the window.  Better
	cache mangement has now fixed this.

v0.35 - (07-Mar-97)
      * Option to use a custom e_clnoff routine added for the benefit of
	SoftWrap mode.

v0.34 - (06-Mar-97)
      * Minimum size of the window (with window wrapping on) increased to be
	equal to the height of the screen.
      * The relative positions of windows' vertical scroll bars are now
	(approximately) maintained as the window is resized.

v0.33 - (04-Mar-97)
      * A better fix for the the 'toggle' icon bug.

v0.32 - (04-Mar-97)
      * Iconisation protocol now supported correctly for windows with
	buttons.
      * The 'window wrap' option implemented.
      * Introduced the '%' command prefix to control whether the window gets
	the input focus before the command is executed.
      * A quick fix for the the 'toggle' icon bug - this makes toggling very
	sluggish.

v0.31 - (03-Mar-97)
      * Convinced myself that the bug causing a severe crash if the
	'toggle' icon was clicked on repeatedly had been cured.
      * Rationalized the syntax of BUTTONS_CHANGE command.

v0.30 - (01-Mar-97)
      * Perl, Strong and Messages modes included in the distribution.

v0.29 - (01-Mar-97)
      * Bug induced by much frantic clicking on multiple close icons cured.

v0.28 - (28-Feb-97)
      * Very severe problems with the cursor block not being set up when
	commands from scripts were being executed cured.
      * Used the width of the "ToolSprites" in the calculations about the
	RHS of the window's area.
      * Button bars' co-ordinate offsets from the corner of the parent
	window are now mirrored automatically if the buttons are attached to
	the opposite side of the window.

v0.27 - (28-Feb-97)
      * Example code provided...
      * Texture mode added to buttons archive...

v0.26 - (27-Feb-97)
      * More low level documentation...
      * ZapObey added to buttons modes.
      * ZapAsm buttons bugs fixed.

v0.25 - (26-Feb-97)
      * ZapButtons icon bar menu bugs fixed.
      * Low level documentation started.

v0.24 - (26-Feb-97)
      * Various bug fixes concerning interactions with other modes.

v0.23 - (25-Feb-97)
      * The !Buttons application created to house the relevant resources.
      * The Templates, Sprites and Scripts files are now loaded separately
	from ZapButtons.

v0.22 - (24-Feb-97)
      * Number of concurrent button bars raised to 96.
      * Modes interfering with button bars on other mode's windows has now
	stopped.
      * Problems with loading the same file twice resolved (again).

v0.21 - (22-Feb-97)
      * Slightly saner memory allocation routines written.
      * RPC specific problems examined and apparently resolved.
      * Number of concurrent button bars raised to 16.

v0.20 - (21-Feb-97)
      * Very, very, very early release.


