Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!elroy.jpl.nasa.gov!jarthur!uci-ics!orion.oac.uci.edu!ucsd!hub!6600pete
From: 6600pete@hub.UUCP (Pete Gontier)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Maintaining scroll bars for multiple windows.
Message-ID: <3715@hub.UUCP>
Date: 24 Jan 90 00:56:01 GMT
References: <1990Jan23.190524.3693@deimos.cis.ksu.edu>
Sender: news@hub.UUCP
Distribution: usa
Lines: 29

From article <1990Jan23.190524.3693@deimos.cis.ksu.edu>, by jxf@phobos.cis.ksu.edu (Jerry Frain):
> Does the ControlHandle tell which ControlDefProc ID I specified at
> creation?

I haven't heard anything to that effect anywhere.

However, if you really want to do things this way, you could
conceivably traverse the control list and compare the defProc
field with GetResource on the scoll bar CDEF.

However, this is kludgy for two reasons:
   Looking through the control list. I can't think of any
      specific reasons why this is bad other than the fact
      that most similar hacks eventually break.
   Looking directly in a data structure which is supposed to
      be maintained by the toolbox.

It's probably best to go ahead and put a handle in the window's
refCon field and store the handles to the scroll bars in it.
Be sure to use SetWRefCon and GetWRefCon even though they are
slower than looking in the record directly. Eventually people
will start doing this as a standard practice and monstrosities
like the auxilliary window list will cease to appear. "Obey the
rules," says Officer MacFriendly.

------------------------------------------------------------------------------
Pete Gontier   | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa
Editor, Macker | Online Macintosh Programming Journal; mail for subscription
Hire this kid  | Mac, DOS, C, Pascal, asm, excellent communication skills