home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Archive Magazine 1995
/
ARCHIVE95.iso
/
discs
/
shareware
/
share_39
/
graph_draw
/
!GraphDraw
/
FntMenuDoc
< prev
next >
Wrap
Text File
|
1990-05-01
|
15KB
|
334 lines
Documentation for the FontMenu module v.1.06
⌐ J.R╓ling 1990
Introduction
As more and more outlined fonts for the Archimedes are becoming available,
a problem arrises for applications accessing these fonts. The number of
fonts is not known in advance, so to create a font menu the application has
to figure out the number of fonts, claim enough space to hold a font menu,
and create it. This can be done in the dull single level (straight foreward)
way. This saves some space, and code complexety, but it is not prefered, as
the user will be presented by a sometimes very long menu containing items
with the same prefix, e.g.
Trinity
Trinity.Bold
Trinity.Bold.Italic
Trinity.Medium
Trinity.Medium.Italic
etc.
The more fonts become available, the longer this menu becomes, the more
irritating it is.
Many applications now are even uncapable of creating menus longer then a
certain amount. Examples of these are !Edit (48 entries), !Draw (64
entries), and even !Impression reacts sick.
When running more then one application with a font menu, there is arises
another disadvantage of this method. Several applications using a identical
menu structure but not sharing the resource, is not the policy of Acorn on
other subjects.
So here is a neat solution for everyone who wants a proper font menu,
without the hassel to create one, and without claiming extra space.
What does FontMenu do ?
The FontMenu module is able of creating a multi-level font menu, and lets
every application share the joy. It contains several SWI's to create, and
access this resource. If no application is using the structure anymore
(because they were all quited for example) the memory for the menu structure
will be realesed by FontMenu, so no unnecessary memory is in use. It has no
problems if more than one font directory is in use. The menu is sorted
alphabeticly (even when more than one font directoris are used), so the user
is able to find the required font at an instance. It requires a minimum of
disc access when a new menu is created. New menus are only created if one is
required, and there isn't already a valid one. When a font menu exsists, and
the user has selected a new font directory, the font menu will be rebuild as
soon as the application accesses this font menu.
FontMenu creates an multi-leveled font menu. In the example above this is a
menu where 'Trinity' occurs only once, but it will have a submenu containing
two items: 'Bold' and 'Medium'. Because there are two types of
'Trinity.Bold' ('Trinity.Bold' and 'Triniy.Bold.Italic') 'Bold' will have
another submenu. In this submenu the first item will be 'Plain'. This name
is made up, but it is more clear then a empty meny entry. The second entry
will of course be 'Italic'.
How does FontMenu work ?
To use FontMenu it is necessary to understand how the Wimp works, and how
to create a application on the Archimedes environment. It is assumed that
the reader understands the above for the rest of this document.
When a application wants to access the FontMenu menu structure, it has to
call SWI "FontMenu_Create" before any other FontMenu SWI's are called. This
will assure that a proper font menu structure will be available. This can be
done on initialisation of the application, but is not absolutly necessary.
When exiting the application, SWI "FontMenu_Release" has to be called, so if
this was the only application using the font menu, FontMenu can release the
memory for it. Every time SWI "FontMenu_Create" is called, a counter is
incremented, and if it was zero (this is the initial value), it will create
a new font menu. When calling SWI "FontMenu_Release", the counter is
decremented, and if it reached zero FontMenu will release the menu memory,
as no application is using the menu structure anymore.
From here on there are two ways of programming when using FontMenu. The
first is the simple one, the second a little bit more complicated, as it
involves the use the Wimp message system.
The easy way
------------
Whenever the user opens the menu structure of the application by pressing
the MENU button, a call has to be made to FontMenu_Select with R0 pointing
to a point sepearted (zero terminated) font string, and in R1 the value 0 or
1 to tell FontMenu if it allows the user to select the SystemFont. The call
will return with a pointer to the font menu structure in R1. Now it is up to
the programmer what to do with this pointer. When passed in R1 when calling
Wimp_CreateMenu, the menu tree will consist entirely of FontMenu structures.
If the font menu should be a submenu of the applications own menu structure,
the pointer should be put in the submenu-word of the parent menu entry, and
Wimp_CreateMenu should be called with a pointer to the applications own menu
structure.
When a menu selection was done, the application should determine by the
returned 'menu tree so far' values if the user selected a entry in the font
menu. If so, it should set an internal flag (say 'FontMenuSelected') to
TRUE, else it should set it to FALSE, so later on it is still known if the
user may have selected a new font. After that it should call SWI
"FontMenu_DecodeFontMenu" with R0 pointing to the first menu selection in
the 'menu tree so far' block wich determines the selected font. R1 should
point to a buffer to contain the answer. This buffer must be at least 48
bytes. If on return of this call R0 > 0, the user selected a new font. The
buffer passed in R1 will contain the font name (a point seperated, zero
terminated font string).
After a menu selction, and taking appropriate actions, the application
should check the mouse button state to see if it has to call SWI
"Wimp_CreateMenu" again. If adjust was used to make the selection, it has to
check the 'FontMenuSelected' flag to determine if the user selected a font
menu entry. If so, it should call FontMenu_Select as discribed above. This
should be done with R0 pointing to the string FontMenu_DecodeFontMenu
returned. The menu pointer returned by FontMenu_Select has to be put in the
'sub-menu pointer' word of the 'Fonts' entry. Now the call to
Wimp_CreateMenu can be done. In this way it is possible for the user to
click with adjust in the font menu, and keeping the menu on screen after the
selection.
There is one little drawback of this method. If the user selected a new
!Fonts directory, it will be noted be the FontMenu_Select code, and a new
font menu structure will be generated. This is always the case, also with
the method discribed below. But it could be possible that the user was going
to do something else in the menu, not selecting a font at all. He could for
instance want to quit. Now he (she) has to wait for the FontMenu module to
create the new menu structure, before he (she) is able to access the 'Quit'
entry. So the next solution is to wait with calling FontMenu_Select, until
the user wants to select a new font. This can only be done by making use of
the Wimp message system. The difficult thing of this method (as discribed
later) is that the Wimp is unable to re-open the menu structure entirely
after a menu selection using the ADJUST button. So a little trick has to
solve this problem.
The hard way
------------
In the applications own menu structure, there should be a menu entry (e.g.
'Fonts') with bit 3 if its menu flags set. The application has to assure
that this bit is set whenever it calls SWI "Wimp_CreateMenu" as it may be
corrupted (see below). So whenever the user puts the pointer above the arrow
on the right of this entry, a warning message (&400C0) will be send by the
Wimp. On receiving of this message, the application should respond by calling
SWI "FontMenu_Select" with R0 pointing to a point sepearted (zero
terminated) font string, and in R1 the value 0 or 1 to tell FontMenu if it
allows the user to select the SystemFont. The font string may be a zero
length string, wich means that no current font is selected. FontMenu will
select the font in its menu structure. If 1 was passed in R1, the first item
in the menu structure will be 'SystemFonts'. In case R1 = 0, this entry will
not be there. This call will return with a pointer to the menu structure in
R1. This pointer should be passed to SWI "Wimp_CreateSubMenu".
When a menu selection was done, the application should determine by the
returned 'menu tree so far' values if the user selected a entry in the font
menu. If so, it should set an internal flag (say 'FontMenuSelected') to
TRUE, else it should set it to FALSE, so later on it is still known if the
user may have selected a new font. After that it should call SWI
"FontMenu_DecodeFontMenu" with R0 pointing to the first menu selection in
the 'menu tree so far' block wich determines the selected font. R1 should
point to a buffer to contain the answer. This buffer must be at least 48
bytes. If on return of this call R0 > 0, the user selected a new font. The
buffer passed in R1 will contain the font name (a point seperated, zero
terminated font string).
After a menu selction, and taking appropriate actions, the application
should check the mouse button state to see if it has to call SWI
"Wimp_CreateMenu" again. If adjust was used to make the selection, it has to
check the 'FontMenuSelected' flag to determine if the user selected a font
menu entry. If so, it should call SWI "FontMenu_Select" as discribed above.
This should be done with R0 pointing to the string SWI
"FontMenu_DecodeFontMenu" returned. As the MenuWarningFlag in the menu
flags of the menu entry (e.g. 'Fonts') preceding the font menu was set
(phhh!), the Wimp is unable to recreating the whole menu tree automaticly.
So a litle trick has to assure that it will work correct. The menu pointer
returned by SWI "FontMenu_Select" has to be put in the 'sub-menu pointer'
word of the 'Fonts' entry, and the MenuWarningFlag (bit 3) of the menu flags
word of this entry should be cleared. Now the call to SWI "Wimp_CreateMenu"
can be done. In this way it is possible for the user to click with adjust in
the font menu, and keeping the menu on screen after the selection. The next
time the user opens the application menu, the MenuWarningFlag (bit 3) should
be set again, as other applications may have used the font menu in the
meanwhile, and it is necessary that SWI "FontMenu_Select" is called just
before the font menu opens.
Because it is possible that SWI "FontMenu_Create" takes some time to create
a new menu, it is recomended that there is a SWI "Hourglass_On" before, and
a SWI "Hourglass_Off" after this call. In case of a SWI "FontMenu_Select",
when Font$Path has changed (so a new font menu has to be created), this call
may take some time aswell, so the two Hourglass SWI's should be used here as
well.
Notes from the author
The reason why I wrote this module, is because I'm not only a programmer,
but also a user who likes to work with the Archimedes. This is because it's
a fast machine and because most parts of Risc-OS allow applications to be
very intuitive. I didn't like the way the available fonts were presented in
most applications, so I started to figure out a proper solution: FontMenu.
I hope that future applications adopt to this method, so please pass it on.
Everybody is free to use it, even in commercial code. The only restriction
is that this document should not be seperated from the FontMenu module, and
that both the module and this document remain unchanged. In case of
commercial use I would like to know this in advance (I could than provide
you with its latest release). My address is at the end of this document. You
can always contact me if you found some bug, or when having other
suggestions.
FontMenu SWI's
Below are the short discriptions of the FontMenu SWI's.
FontMenu_Create &8D080
----------------------
On entry: --
On exit : R0 = Number of fonts found
This will create a font menu structure in RMA, if not already done so. An
error occurs if there is not enough room in RMA to create the menu.
FontMenu_Release &8D081
-----------------------
On entry: --
On exit : --
This will release the memory taken by the font menu if no tasks are using
it anymore.
FontMenu_Select &8D082
----------------------
On entry: R0 = pointer to point seperated, ctrl terminated font string
R1 = SystemFont flag
On exit : R0 = State flag
R1 = pointer to font menu structure
This will tick the font passed in R0 on entry. R1 determines if
'SystemFont' should occur in the menu as follows:
Value Meaning
0 'SystemFont' does not occur in the menu
1 'SystemFont' does occur in the menu
On exit R0 shows the selection state as follows:
Value Meaning
0 To be selected font not found, no ticks
1 To be selected font found, and ticked
2 No font entries found, menu consists one item; 'SystemFont',
and is ticked
R1 will point to the font menu on exit. An error occurs if no font menu exists.
FontMenu_Deselect &8D083
------------------------
On entry: ---
On exit : --
This will clear all ticks and marks of the font menu. It is not necessary
to call this SWI before a FontMenu_Select call, as FontMenu_Select will take
care of cleaning up old selection. An error occurs if no font menu exists.
FontMenu_DecodeFontMenu &8D084
------------------------------
On entry: R0 = pointer to a list of font menu selections
R1 = pointer to a buffer to contain the answer
(at least 48 bytes long)
On exit : --
This will decode the font menu selection into a font string for the
FontManager. This string can be passed back to FontMenu_Select to tick the
appropriate entries. An error occurs if no font menu exists. This call makes
use of Wimp_DecodeMenu, but as it is possible that the returned string ends
with 'Plain' (a made up name to distinguise an empty sub-name from the rest
of the sub-names), it has to check for this, and throw away this last
sub-name so the FontManager can recognise the required font.
FontMenu_Smash &8D085
---------------------
On entry: --
On exit : --
This will release the font menu memory without looking at the amount of
times FontMenu_Create was called.
FontMenu_ReCreate &8D086
------------------------
On entry: --
On exit : R0 = Number of fonts found
This will release a existing font menu, and recreate it.
===========================================================
To contact the author of FontMenu, please write to:
Joris R╓ling
Verlengde Willemstraat 8a
9725 AW Groningen
The Netherlands
Telephone: 050-271895