[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
Daniel J Birks <dqb@cs.bham.ac.uk> writes:
> Date: Mon, 29 Nov 1999 15:33:11 +0000
>
> Just a quick note,
> Does anybody know the most efficient method of creating new rc sheets from
> pressing on an action button in another sheet (ie for use in a GUI) To
> allow multi-level interfcae to be implemented..
> Currently I am dropping back into the POP11 compiler (from the action
> list) and calling a procedure which creates a new sheet using
> rc_control_panel(x,y, fields,'InterFace etc').
>
> Surely this is not the most efficient method of doing this.
What makes you think this inefficient?
Are you talking about run-time efficiency or ease of programming?
If you are worried about repeatedly creating panels, this may matter
less than you think because the pop-11 garbage collector is so fast
(as long as you don't repeatedly lock and unlock the heap while
using X facilities).
However, if you wish to have a sheet available which is created only
once then re-used you can use rc_hide_window (or rc_hide_panel) and
rc_show_window on the result of rc_control_panel.
See HELP RCLIB (which is not yet complete, alas -- though the procedure
definitions can be inspected if you do "ENTER showlib rc_window_object"
after "uses rclib".)
There is a related mechanism provided in the rcmenu package, made
available by
uses rcmenu
This was recently converted to use rc_control_panel, instead of
propsheet. For an introduction see TEACH VED_MENU. It allows the use
of this format:
define :menu ....
....
enddefine;
It also introduces the option to include in a control panel a button
of the form
[<label> [MENU <name>]]
e.g.
['Dired...' [MENU dired]]
This shows a button on the control panel with the word or string
<label> and if selected (mouse button 1) it autoloads a panel
defined in the file menu_<name>.p in one of the directories in the
list of directory names:
menu_dirs
That is a list of directories containing autoloadable control panel
definitions. The default collection is in
$poplocal/local/rcmenu/menus/menu_*.p
If the panel definition was previously compiled the panel is merely
shown (if hidden) and not re-created.
(The VED command "ENTER menu <name>" uses this autoloadable
menu mechanism also).
When using rc_control_panel, if you have done
uses rcmenus
then you can use the [MENU ...] action button format to create a button
within an
[ACTIONS ....]
list in the panel specification for rc_control_panel.
(This should be added to the documentation on rc_control_panel.)
I have been thinking of extending rc_buttons and rc_control_panel
to allow something similar but more general, e.g.
[<label> [PANEL x y fieldspecs title ...]]
[<label> [SUBPANEL x y fieldspecs title ...]]
where the second creates (or shows) a (possibly movable) sub-panel in
the current panel (as illustrated by use of container argument in the
existing file HELP RC_CONTROL_PANEL).
The arguments for the panel or subpanel would be the same as the
arguments that rc_control_panel now has. However this would
probably have to compile into a [POP11 ....] action specification
when the specification is read in.
I don't know when I'll have time to get around to doing this. If
anyone wants to try it will require some changes to the allowed
action formats in LIB RC_BUTTONS.
It may suffice to change this method
define :method modify_instance(
button:rc_action_button, contents, type, specs);
Maybe it would be useful to extend LIB async_interpret_action
instead of compiling a [PANEL...] or [SUBPANEL...] action
button spec into a [POP11 ...] action button spec.
I have not thought it through.
> Sorry if I've been stupid and overlooked something but most of the
> examples GUI's I've found use a single sheet and are therefore not very
> useful to me.
You could look at
TEACH RC_ASYNC_DEMO
TEACH RC_CONSTRAINED_PANEL
both demonstrate linked panels.
There's more about sub-panels in HELP RC_CONTROL_PANEL.
Aaron
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
|