Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!tecot
From: tecot@Apple.COM (Ed Tecot)
Newsgroups: comp.sys.mac.programmer
Subject: Re: TrackControl() problems
Keywords: TrackControl, CDEF
Message-ID: <35247@apple.Apple.COM>
Date: 4 Oct 89 00:19:36 GMT
References: <2838@murtoa.cs.mu.oz.au>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 32

In article <2838@murtoa.cs.mu.oz.au> rob@cs.mu.oz.au (Robert Wallen) writes:
>I dont know whether this is me not reading enough of Inside Mac (can you
>really do that anyway?) or have I hit a 'bug'?

The 10/89 revision of Technical Note #196, 'CDEF' Parameters and Bugs
addresses this issue.  Basically, Inside Macintosh is wrong on several counts.
I don't know if the notes have made it out, so I'm reproducing the new
information here:

posCntl (5) and thumbCntl (6)

According to Inside Macintosh, the Control Manager calls a 'CDEF' with the
posCntl message and the thembCntl message if an application does custom
dragging of an indicator (a thumb), but not if it does default dragging.
This is not true.  The Control Manager calls a 'CDEF' with the posCntl message
if an application does default dragging, which is exactly the opposite of the
way it is documented.  The 'CDEF' receives the thumbCntl message regardless
of which type of dragging the application does, however the results are used
only for default dragging (they are ignored for custom dragging).

_TrackControl

When a user clicks on your control, you normally call _TrackControl, which
is supposed to return zero if the user does not change the control's setting
or the part code if the user does not change the setting.  For 'CDEF' resources
that implement custom dragging, _TrackControl returns zero whether or not the
user changes the control setting.  To work around this problem, you must use
another method to find out if the user has changed the control's setting,
such as comparing the control's value before and after the call to
_TrackControl.

						_emt