[comp.sys.mac.programmer] Need MacApp Help ...

kn@doc.ic.ac.uk (Keng Ng) (06/07/90)

I'm creating a TPalette class in MacApp to implement the kind of tool
palettes you see in MacDraw windows. It contains subviews of type
TPaletteIcon which represent the individual tools.

I've made TPalette a sub-class of TControl and TPaletteIcon a subclass
of TIcon. My intention was to have a field called fCurrTool in
TPalette which will be a reference to the current tool (i.e. a
TPaletteIcon object), and have this field initialised in the IRES
method of TPalette to the default tool.

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 ?

I've thought of just making fCurrTool an integer which corresponds to
the position of the tool within the palette, but this will mean more
work when it comes to hiliting/unhiliting the tools, since there
doesn't seem to be a direct way of retrieving the n-th element of a
list. My current 'fix' is to make fCurrTool record the fIdentifier of
the current tool, and call FindSubView to retrieve it when necessary.

Perhaps the question I should really ask is : does what I'm doing
above look sensible ? I'm new to OOP and MacApp and working without
the 'MacApp Cookbook' and 'Intro to MacApp ...' manuals doesn't make
life any easier. (I'm waiting to hear from ADG, the U.K. equivalent of
APDA).    Oh, I'm using MacApp 2.0b9 with Think Pascal 3.0.

---------------------

Keng Ng
Dept of Computing
Imperial College
180 Queen's Gate
London SW7 2BZ
Tel: +44 71 589 5111 ext 5091

anders@penguin (Anders Wallgren) (06/07/90)

One thing you could do is get (from AppleLink if you have access, or
from me if you don't) the PostRes package.  This is a change
(third-party - not Apple) to the TView structure that adds a PostRes
method which gets called after the IRes method of an object _and_ all
its subviews is complete.  It does what you want it to do.

anders

sla@brillig.umd.edu (Steve Armentrout) (06/07/90)

In article <1963@gould.doc.ic.ac.uk> kn@doc.ic.ac.uk (Keng Ng) writes:
>
>...there doesn't seem to be a direct way of retrieving the n-th element 
>of a list. ...

You are probably looking for more of an answer than this, but...

	TList.At(n) returns the nth element of a list

Hope this helps,
Steve

lsr@Apple.COM (Larry Rosenstein) (06/08/90)

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