Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!usc!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need MacApp Help ...
Message-ID: <8615@goofy.Apple.COM>
Date: 7 Jun 90 22:15:47 GMT
References: <1963@gould.doc.ic.ac.uk>
Sender: usenet@Apple.COM
Organization: Future Stuff,  Apple Computer, Inc.
Lines: 51

In article <1963@gould.doc.ic.ac.uk> kn@doc.ic.ac.uk (Keng Ng) writes:

> palettes you see in MacDraw windows. It contains subviews of type
> TPaletteIcon which represent the individual tools.

I did this by making TPalette a subclass of TGridView.  (See the book
"Programming with MacApp".)  But your approach is equally valid.

> However, it seems that the fSubViews field of a view is not set up at
> the time its IRES method is called. Does anyone know of a workaround ?

This has been discussed on AppleLink.  One person changed the MacApp 
sources to add a new method called PostRes, which is called after the view 
hierarchy is built (using calls to IRes).  You could then get the 
fSubViews field in the PostRes method.

If you don't want to change MacApp, then there are 2 approaches:

(1) Provide a method in TPalette that clients call after the views are 
created.  This method would then retrieve the necessary subviews.  (This 
is simply a manual form of the PostRes call.)

(2) Implement a method in TPalette that returns the desired subview.  This 
method would check to see if the field was NIL and if so, call FindSubView 
to locate the subview, and cache the result in the field.  The rest of the 
TPalette implementation would have to use the method instead of accessing 
the field directly.  

This is very clean and puts the burden on the implementor of TPalette 
instead of its clients.  Calling a method in this case won't be 
inefficient, because in the final version of your program the call will be 
optimized to a direct procedure call.

> doesn't seem to be a direct way of retrieving the n-th element of a
> list. 

Try TList.At.

> My current 'fix' is to make fCurrTool record the fIdentifier of
> the current tool, and call FindSubView to retrieve it when necessary.

Option 2 above is similar, except that you only pay the cost of 
FindSubView once.

Let me know if you have any other questions.

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1