🚀 go-pugleaf

This posting is on request of Herbert zur Nedden.
I will forward any replies to him.

-----------------------------------------------------------------
Not very short but less than 1% quoted from other sources :-).

I like Tim Browse's ideas. Here are a few of mine as for 'how does the program
use the tags and where are they stored ...'

I've been thinking about named menu items quite a while since it is easier to
write programs reacting to a menu selection "QUIT" instead of "item no. 3".
This is especially true when you insert a new menu item ... renumber!
The SWI Wimp_DecodeMenu is not worth alot if you want to write applications
using the MessageTrans module for internationalisation.

In my solution I decided that each menu item has a tag which
- is the tag for the MessageTrans module, i.e. the text displayed is
  read from the message file.
- gives the item a name you can use in the program.

When creating the menu structure for the SWI Wimp_Createmenu the tags are
stored directly after the last item of the menu, prefixed by an eyecatcher.
The eyecatcher is to make sure that whatever resides after the menu in
memory is not misunderstood, i.e. to be able to detect menus whose items
don't have tags. That can be the case for color selection menus since
tags aren't really needed for these.

Instead of the SWI Wimp_DecodeMenu a function decodes the block returned
by Wimp_Poll and returns several informations:
- The path based on the tags
- The tag of the selected item
- The level where the selection occured.
- A pointer to the item in the menu structure (e.g. for setting the tag).
Menu items without tags are given numeric names 0000, 0001, ....

The path is not stored as a long string but as an array of item names. Nor-
mally the path isn't needed as a whole so why construct that long a string.
Another function can be used to locate a menu item using the item's tag only.
Well to be precise two of them are needed: FindFirst and FindNext just in
case the item's tag is not unique.

I didn't give the menu itself a name. Basically since there is only one active
at one time anyhow; so what for? On the other hand each sub menu is a menu
as well leading to the question: 'shall sub menus have names'. If this is
answered with yes, well what do you store in the path. The name of the top-
most menu and the tags thereafter? Or are the submenu names included as well?


Maybe for windows something like this can be adopted as well. It is a little
more complicated since icons can be added while a window is open, but those
icons probably are not the problem anyhow. But storing the tags in memory
somewhere where they can be found would be nice.

I'm neither into using the RiscOsLib nor the DeskLib - I stick to the GagLib
(the C library being written by Olaf Krumnow and me, GAG being the abbrevia-
tion of German Archimedes Group). Therefore it would be nice to be able to
implement Glazier-Templates in our libray as well. Perhaps you or someone
else could write a module to offer Gazier_Template-SWIs as replacement of
the Wimp_Template-SWIs which load them in memory in a decent way, i.e. so
that the program can start using them right away and not as e.h. with normal
templates has to get storage for the indirected buffers ...

Herbert zur Nedden

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

Olaf.

------------------------------------------------------------
Olaf Krumnow                 e-mail: okrumnow@mcshh.hanse.de
                             snail : August-Bebel-Str. 102c
Headquarter of the                   W-2050 Hamburg 80
German Archimedes Group              Germany
------------------------------------------------------------