Path: utzoo!attcan!uunet!bloom-beacon!usc!gem.mps.ohio-state.edu!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!cbnewsk!ech
From: ech@cbnewsk.ATT.COM (ned.horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: gGopher question
Message-ID: <1063@cbnewsk.ATT.COM>
Date: 22 Sep 89 18:45:34 GMT
References: <1989Sep21.050812.15192@agate.berkeley.edu>
Organization: AT&T Bell Laboratories
Lines: 73

In article <11945@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes:

>I am writing a special purpose drawing program in Think C 4.0, and I need
>help.  (The drawing portion of the program is a major part of a 3-D simulator.)

>2) Should the Ancestor class of the drawn objects be CBureaucrat?
>    (Drawn objects respond to commands, keys, and mice, so I guess so.)

From article <1989Sep21.050812.15192@agate.berkeley.edu>, by fjlim@garnet.berkeley.edu:
> ...Mouse clicks are "sent" to the Pane
> which is clicked on. Your drawing objects will not receive DoClick()
> messages unless you make each one a separate Pane (not a good idea).

> I recommend making your drawing objects subclasses of CBureaucrat and
> setting the gGopher to the current selected drawing object. The alternative
> is making the Pane act as a middleman which dispatches key clicks and
> menu commands to the appropriate object. This places too much knowledge
> in the Pane. You would have to change code in the Pane's methods if you
> added another kind of drawing object.

I hate to try to tell grandma how to suck eggs, but...

I'm fairly new to this object-oriented way of approaching things, so
please bear with me; if I've got my head wedged, please help me get it
loose...

If the drawn objects are themselves CViews, in the pane's "itsSubviews"
CList, then the DispatchClick() routine ought to "do the right thing"
without any special knowledge in the pane at all.

I'm presuming here that the drawn objects are themselves subclasses of
CView (but not necessarily of CPane).  By appropriately overriding
the Contains() method (and setting wantsClicks), Mr. Palmer's visual
objects should get DoClick() messages appropriately.  Setting
	gGopher = this;
in the drawn object's DoClick() method would then cause subsequent
commands to be sent to the right place.

Note that in the class library as distributed, there's no real support for
the CDirector::itsGopher variable.  It seems to me that a CBureaucrat access
method would be a good idea here.  Alternatively, you might override
DispatchClick in your Document subclass to do something like

	inherited::DispatchClick(...);
	itsGopher = gGopher;

this would be particularly sensible if CView::DoClick() was

	gGopher = this;

(presently CView::DoClick() does nothing).

As a more general comment, any CView might wish to override DispatchClick()
to record the fact that one of it's subviews (or descendants) had become
the gopher.  This is pretty straightforward as things stand: a CView
only gets a DispatchClick() message if it has wantsClicks set and it
responds TRUE to a Contains() message, i.e. it is true that a CView
gets a DispatchClick if and only if it or one of it's subviews receives
(the) DoClick message.  As a general design rule, any CView that becomes
"active" (i.e. the gopher or one of it's visual ancestors) may need to
respond in some way (typically a change in appearance).  I don't think
this is adequately reflected in the pristine class libraries, but again,
please correct me if that's a misapprehension.

Going the other way, the distributed CDirector/CDocument etc. classes
don't do anything to "get the word out" on an Activate message.  As
a general rule, one would want to not just set "gGopher = itsGopher",
one would also like to pass the Activate along to gGopher and its
ancestors.

Comments?  Suggestions?

=Ned Horvath=