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