Class visual is a superclass of all classes who's
instances normally causes a direct visual effect on the display. Of
course this entails the classes graphical and window. In addition it
entails classes such as dict_item (which is visible in a browser) and
display (which represents the entire screen). Class visual
serves two purposes:
<-contained_in
and visual<-contains
define a hierarchy of visual
objects. This hierarchy allows one to examine the visual world
of PCE and to determine relations between visual
objects. This hierarchy is used by the‘Visual Hierarchy’browser
of the manual tools.
The methods visual<-contained_in
and visual<-contains
actually are empty. Each subclass of visual provides the appropriate
definitions.
Note that the display_manager object @display_manager is the root of the consists-of hierarchy.
<-contained_in’.
A visual is defined to be contained in itself.->free
on the visual and all parts of this visual that are not protected. This
method may be used to destroy an entire tree of
visual objects.
First, it collects all visuals that are part of it and not protected
or part of a protected visual using visual<-contains.
Then it will send free to all collected visuals. This method takes care
of the fact that freeing one visual might result in the destruction of
others.
->report
provides a general mechanism to present short descriptions of status,
warnings or errors to the application user. This method is integrated
with the general error reporting mechanism (see
object->error
and class error.
If no visual
object is available to send the report to, object->report
may be used.
The first argument describes the type of the message to be reported.
The type is an indication on how serious the message is and
thus how much attention it should attract from the application user. Its
values are:
status, but if no appropriate location can be found it will
invoke display->inform.
status, but followed by a
graphical->flush to take immediate effect.
->report:
progress messages.
->alert
suffices. If there is an appropriate location for the message it will be
formatted there.
The remaining arguments are a format specification and format
arguments. See string->format
for details on PCE's formatting capabilities.
The method visual->report
performs the following steps:
<-report_to.
->report
message. @reportee
thus points to the original visual
object that received the
visual->report
message.
->report
with the same argument on the object. The method visual->report
is redefined by various subclasses. The most important are: label->report, frame->report
and‘display
visual->report’.
->reset
to all visual objects
it contains (recursively). visual->reset
is automatically invoked from the
host-language
after an abort to the hostlanguage toplevel. Various subclasses of
visual implement this method to reset parameters such as status,
event-focus, etc.
Bugs: Recovery after a crash or abort is not very save. The consistency of the objectbase may be violated, gesture objects often cannot be tracked and reset, etc.
parent visualiser. Defined at each of the
various subclasses of visualiser to deal with the different
implementations. All visualiser classes define this method. The object
@display_manager
is the root of the hierarchy.
See also visual<-contains.
Using the manpce/0
window, the menu Tools/Visual hierachy provides a tool for inspecting
the actual hierarchy.
|code -> condition=visual@arg1 Visual object considered
Providing a class argument is a shorthand for
message(@arg1, instance_of, <class>).
See also visual<-contains, visual<-contained_in, graphical<-window,
graphical<-frame
and graphical<-display.
compound
visualiser defines this method to deal with it's particular
implementation.
<-contained_in
to walk up the consists-of hierarchy of graphical
objects until it finds and instance of class frame.
Fails silently if no frame can be found, which is the case if the
receiver is not displayed, is a display
object or @display_manager.
See also visual<-container, graphical<-window
and graphical<-device
stand-alone visual of this visual. This
definition is vague and its implementation is equally ill defined. The
idea is illustrated in the view <-> editor example:
If the programmer creates a view
object, s/he creates a specialised window with an editor displayed
inside it. The view delegates to its
editor object and the
programmer does not have to be aware that the view consists of multiple
objects. Class editor
however sometimes invokes associated messages (for example editor<->error_message.
We would like to retain the invisibility of the multiple objects by
binding @receiver
to the view rather than to the editor itself.
The visual<-master
method is a (bad, but we needed something) attempt to solve this
problem. It knows about some of these combinations and will return the
proper main object.
Defaults: Visual
objects that have not redefined this method return object<-self
Bugs: This method should not be there. As soon as a better
solution to this
composite object problem is found we will replace this.
->report.
By default this is the same as
visual<-contained_in.