🚀 go-pugleaf

In article <1992Apr8.062804.14719@trl.oz.au>, you write:
>
> In grview.c ( from the library ), there is this member
> function of GraphicView, which is advertised as
> "Return the viewer( if any) that displays the view )"
>
> The actual member function is as follows...(From lib)
> Viewer* GraphicView::GetViewer () {
>     GraphicView* parent = (GraphicView*) GetParent();
>
>     if (parent == nil) {
>         return nil;
>     } else {
>         return parent->GetViewer();
>     }
> }
>
> Now this will always return nil, as it is
> 'recursive' UNLESS there is some GraphicView which explictly
> has overloaded GetViewer to return a useful value. [ y/n
> am I on the right track ?]
>
> This seems a little unusual, I would think that a view
> should always be able to find its viewer...

Notice that the GraphicView class does not store a pointer to a
viewer.  In fact, none of the predefined GraphicView subclasses do,
not even GraphicViews.  This is because drawings may have many
GraphicViews in them (e.g., defining groups of components), and having
a pointer to the enclosing viewer in each would create unnecessary
overhead.

Instead, the viewer defines a component view called a ViewerView that
serves as the top level view in the hierarchy it displays.  The
ViewerView's presence is transparent the programmer---all you should
need know is that a Viewer contains and displays the GraphicView you
(optionally) gave it.  It is this ViewerView instance that stores a
pointer to the enclosing Viewer (which created the ViewerView in the
first place), and it is the ViewerView class that overrides GetViewer.
That way, only one view needs to store a pointer to the enclosing
viewer.  Moreover, if there's no ViewerView in the hierarchy, then
obviously there's no viewer.

--
John Vlissides / IBM T.J. Watson Research / vlis@watson.ibm.com