Here, each %v directive gives rise to a pin in input
connector 0, each %t directive gives rise to a further
string input connector. As the only example#1,
we illustrate how to make a scrolling text output window: each exec step
of the circuit adds another line to the displayed text, scrolling existing
text upwards, when the window is full.
Each embedded output area is identified by a name (and is often referred to as a "named area"). The name of an area must coincide with the window title of the graphics window that shall appear in that area. For example, the directive
%200:300=foo
will set aside a 200x300 pixel rectangle named "foo" that initially appears as a blank, sunken area (try it out, e.g., with an input_window unit). If you now create, e.g., a plot_xy unit and specify as its window title also "foo", its window will appear inside the named area "foo" (if the plot_xy unit already exists, its window will relocate itself into the named area only after the unit is modified, i.e., re-created; try both possibilities!). Some units, such as the plot_xy unit, will automatically resize their window to fit into the named area, others (like the write_pix unit) will insist on their window size and appear clipped or leave unused space in case of a mismatch.
Colormap areas. These are ok for all types of colormap windows (which includes the windows of plot_xy, plot_vec, plot_series, plot3d_unit and monochrome write_pix units). The specification is
%width:height=windowname
RGB areas. These are required for RGB windows, such
as the write_pix unit when created
in RGB display mode.
A specification is
%width:height=:windowname
GL-3d areas. These are required for 3d-rendering windows for solid objects, using GL graphics (units that create such windows are the view3d and the camera_unit). The specification is
%width:height=::windowname
Text areas. These are actually Colormap areas, but intended for embedding the window of an output_window unit. Therefore, unlike the three previous types, their size is specified in character units. The specification is
%width:height==windowname
Text areas admit two additional shorthands
%width==windowname
%=windowname
The first form assumes height=1 (one line), the second form assumes in addition width=10 chars (the default width of a numeric entry field). Note that when no size argument is given, a single '=' suffices.
Example#3 is a window with all four window types.
The previous example is ok. for pixel-sized color map windows. For a pixel sized GL window, the '=' must be replaced by a '=:'. For a character sized color map window (e.g., from an output_window unit), the '=' must be doubled to '=='. In this case, the width and height are expected in characters, not in pixels. Finally, to accommodate just the output from a one-line output window of, e.g., 30 chars width, the short form %30=foo may be used (i.e., only the width need be given, and a single '=' suffices).
For text areas, the optional 3rd parameter can be used to choose between "sunken" form (value=1) and "flat" form (value=0).
If an output rectangle in a input_window is followed by a vertical slider with no size specification (such as %0:1s^), the height of the slider is made equal to the rectangle height (try it).
Technically, the area of a named area is considered a belonging to the area of the enclosing input_window or output_window only, if the named areas is used to trigger callbacks. I.e., when the mouse pointer moves into a named area that triggers no callbacks (i.e., is not followed by %!..!name), this is also considered as leaving the enclosing input/output window. This point can be useful occasionally when structuring interactive programs.