🚀 go-pugleaf

In article <1845@utah-gr.UUCP> thomas@utah-gr.UUCP (Spencer W. Thomas) writes:
>
>I think you are hitting a well-known bug in the handling of scroll bar
>controls.  It is even documented in IM (if you know what you are looking
>for).  The actionProc will be called with two arguments (the control
>handle and the part code), *except* when moving the thumb.  In assembly
>language, you can do a hack to try and determine which it is (since you
>want to just return for thumb actions, anyway), by looking at the
>supposed "theControl" argument and seeing if it is the handle to your
>control.  This is not certain, since the garbage on the stack could
>possibly have the same value you are looking for. 
>

Another way to solve this is to note that a control defproc can also handle
tracking (although the default scroll bar defproc does nothing).  If -1 is
stored in the contrlAction field of the scroll bar, then the defproc will be
called with the autoTrack message.  Since this is a defproc call, the
interface is the same for clicking in the arrows as dragging the thumb.

To get your action procedure to be called you must take the defproc handle
out of the scroll bar, save it, and install a handle to your new defproc.
(You should be able to use a "fake" handle created in global space.)

Your defproc simply calls the original defproc for every message except
autoTrack.  For the autoTrack message you simply do the appropriate thing in
your dialog.


(A bit of Macintosh trivia.  The reason why the thumb tracking proc takes
no parameters is because thumb tracking is done with a call to DragTheRgn,
and the actionProc accepted by DragTheRgn takes no parameters.)

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET