Description
This tool is designed for use when context sensitive menus are
required. For example, it was implemented for use with annotations,
since clicking on a new shape should bring up options for that
shape. This allows different ``types'' of autoguis to be built, one
for each type of shape. The autoguis are
built only once, since construction of them takes a significant amount
of time. Once built they are mapped, and unmapped from the screen as
needed. This widget also attempts to make accessing multiple autoguis
simpler, by allowing ``nested'' options within the records passed to /
from it. For example, you can construct a multiautogui, and have
it generate multiple autoguis, all with their parameters filled, by
forming the fillgui record correctly. Most of the work is still
done by the underlying autoguis.
Parameter description
In a similar manner to autoguis, most
transactions occur via ``parameter records''. In addition to this are
control functions, which control the mapping to and from the screen of
the different autoguis. The actual records destined for the desired
autogui are nested one level down. For example, if two autoguis are
desired, ``someoptions'' and ``otheroptions'' and you wish them both
to occupy the same spot on screen using a multiautogui, you would
create a parameter record as follows, construct the widget, and then
choose which one you wanted visible:
- myoptionrecord:
- someoptions: This is the name you will use to refer to
operations on this autogui, and also the name which the multiautogui
will return new options for this set under
- options: A standard option set for an autogui
- otheroptions: This is just some other name.
- options: Another different standard option set for an autogui
include 'multiautogui.g'
mymulti := multiautogui(myoptionrecord, title = 'Test Multi');
mymulti.show('otheroptions');
For a complete example, see multiautoguitest in multiautogui.g . A
similar technique is used to fill the GUIs, and also to receive
options from them.
Event description
Basically, anytime one of the autoguis being
maintained by multiautogui fires a setoptions event, it is passed on by
multiautogui. The difference is multiautogui stores the parameters
returned by the autogui in a record which has the name of the
parameter set. The example above, in which we created two autoguis
called ``someoptions'' and ``otheroptions'' provides a good way to
demostrate this. We imagine that ``someoptions'' was visible,
and the user changed a parameter. Multiautogui would emit a setoptions event, which contained a record with one field. The field
name would be the originating autogui (in this case ``someoptions''),
and contained within that subrecord would be the new options.
Similarly, when a newuserchoicelist is emitted (in fact, all
events (*) are forwaded on in this manner), the same
``parameter encoding'' occurs, with the option record being stored in
a subrecord, the name of which is determined by the originating
autogui.
News 
