Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!garnet.berkeley.edu!fjlim
From: fjlim@garnet.berkeley.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: gGopher question
Keywords: THINK Class Library
Message-ID: <1989Sep21.050812.15192@agate.berkeley.edu>
Date: 21 Sep 89 05:08:12 GMT
References: <11945@cit-vax.Caltech.Edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: fjlim@garnet.berkeley.edu ()
Organization: University of California, Berkeley
Lines: 63

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.)
>
>3) The documentation for CBureaucrat says that a Bureaucrat should handle
>    Keys and Commands, which are automagically passed to it when it is
>    the gGopher, but it doesn't say what happens to Mouse clicks.
>    Are they also sent to the gGopher?
>
>4) What should the flow of control be?  Should the selected drawing object
>    become the gGopher (or the Pane if nothing is selected), or should
>    the Pane (or the Document?) handle mouse clicks and commands, passing
>    them on to the currently selected object?

The answers to these three questions are related. It depends on how you
want to structure your program. 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.
>
>5) Can an Object be written-to and read-from a file in the standard
>    manner? (with the Mac equivalent of
>	 fwrite(*Object, sizeof(object), 1, stream)
>    where *Object is the first argument and singly indirects the handle
>    of Object to get a pointer.)  How are objects within objects best handled?
>    (By which I mean references to objects.  For instance, each object
>    may have a list of the objects touching it, etc.)
>    I am currently planning to keep all objects in lists, and, at save time,
>    replace the contained object's handle with an index into the list.  It
>    is ugly, but I can't think of any other way to do it.
>

Objects are stored in memory as handles, so the simplest method of
storing them to disk is as resources. Just use AddResource calls.

In your case, however, you'll want to use the data fork since there
could be many drawing objects. The only data for an object is the
values of its instance variables (including those it inherits) and
an additional two bytes (BEFORE the instance variables) which is
used by the runtime environment for method dispatching.

The Mac Toolbox call
	FSWrite(fileNum, &objSize, *Object+2);
will work.

As for references to other objects, you'll need to replace the pointer
to the object (4 bytes) with some kind of index number for how you're
storing objects in your file. When you read the object back into
memory, you can replace the index number with a pointer. The Toolbox
uses a similar technique for resources within resources (see IM I-127).

---
Gregory Dow