Home |
|
Viewports
|
Index |
|
Viewports are rectangular areas of the screen, each owned by
a particular KwikPeg object. Each viewport has only one owner.
However, one object may own several viewports.
The figure shown below illustrates a typical runtime screen image.
The light gray area represents the screen background.
The two white areas with title bars are KwikPeg windows, named
WindowA and WindowB. WindowB is on top of WindowA,
partially overlapping it. The areas bounded by solid dark
gray rectangles depict the viewports owned by the KwikPeg
Presentation Manager, the PegPresentationManager
object. The Presentation Manager owns the viewports labelled
V1 to V6. WindowA is divided into two viewports (V7 and V8),
both owned by the WindowA object.
WindowB has a single viewport (V9) which is owned by the
WindowB object.
KwikPeg maintains the screen viewports. Your application
will generally be unaware of their existence. Normally, only
window objects derived from the PegWindow class
will own viewports. Other objects within the window, like
PegButton and PegIcon, will not own
any viewports; they simply inherit access to the viewport(s)
of their parent window.
The KwikPeg viewport management algorithm does not permit
discontinuities in its list of objects owning viewports. Hence,
an object that owns viewports (a PegWindow derived object)
must only be added to another object that owns viewports.
This condition is usually met because most windows are added
to other windows or to the Presentation Manager which is
itself a window.
However, in some circumstances, a PegWindow derived
object may have to be added to an object which does not own viewports.
Fortunately, KwikPeg offers a solution which makes this
operation possible. To solve the problem, you must be
viewport aware. The following example will clarify the issues.
Suppose that you want to create an object container class,
say ThingGroup, to manage a group of lists,
windows and other controls. The ThingGroup acts
as a holder but has no visible presence on the screen.
A ThingGroup object can then be added to
(removed from) any other object, effectively adding (removing)
the entire group of objects.
Now suppose that, for simplicity, the
ThingGroup class is derived from the
PegThing class, the most basic KwikPeg class.
A ThingGroup object will therefore not be able
to own viewports because it is not derived from the
PegWindow class. Consequently, none of its
children will ever be visible on the screen. Furthermore,
the ThingGroup object will not be able to have
children which are PegWindow derived objects,
contrary to the stated purpose of the
ThingGroup class.
The problem would not exist if the ThingGroup
object could own viewports. Fortunately, KwikPeg permits you
to use the AddStatus() member function to set the
PSF_VIEWPORT status flag of a ThingGroup
object, thereby permitting the object to be a viewport owner.
The ThingGroup constructor must issue the following
call at some point after the PegThing base class
constructor has been executed.
AddStatus(PSF_VIEWPORT);
Once ThingGroup objects are viewport enabled,
their children, including those derived from the
PegWindow class, will be properly displayed on
the screen whenever the ThingGroup object is "visible".
