mnkonar@srcsip.UUCP (Murat N. Konar) (09/12/88)
I am trying to write a CDEF and have run into a few places where there is an
apparent inconsistency between IM's description of how
the Control Manager interacts with CDEF's and reality. In particular:
1) When the CDEF is called with a message of drawCntl, the value of param is
supposed to be the part code of the control to draw. The gotcha here
(not mentioned in IM) is that the part code is in the low order word only
so you must mask off the upper word or do something like
thePartCode:=loWord(param)
2) The section titled "The Position Routine" (IM I-331) states that controls
that don't use the Control Manager's default method of dragging must include
a position routine. This implies that controls that DO use the default method
DO NOT need a position routine, yet when I tell the Control Manager to use the
default method (by returning zero in response to a dragCntl message), I am
still receiving a posCntl message. Infact, if there is not a position routine,
the indicator will not get updated. Apparently, using the default method of
dragging does not exempt you from having to provide a position routine.
3) The section titled "The Thumb Routine" (I-332) says that the Thumb
Routine is only needed for controls that don't use the Control Managers
default method of dragging the indicator. This is contrary to what I have
observed. It appears that you need the Thumb Routine ESPECIALLY if you use
the default dragging method.
And now a question:
The sequence of messages that a CDEF receives when the Control Manager is
executing the TrackControl function for a control that uses the default
method of dragging is as follows:
testCntl
thumbCntl
dragCntl
calcCRgns
posCntl {only if start Point <> end Point}
The Control Manager uses dragGrayRgn to do the indicator dragging. If the
start point (the point where the mouse was first pressed) is equal to the end
point (point where mouse is released), TrackControl returns zero. If the start
and end points are different and the end point is within slopRect, TrackControl
returns the part code of the indicator. If I choose to do my own indicator
dragging, I get the following message sequence:
testCntl
thumbCntl
dragCntl
but TrackControl returns zero no matter where I release the mouse. How do I
tell the Control Manager what value TrackControl is supposed to return?
If anybody could answer this question or point me to an authoritative source
on writing CDEFs (I've already seen the MacTutor articles on definition
functions, they are woefully inadequate) I'd really appreciate it.
Respond either directly or via the net. Many thanks and a garland of
Martian Fire Flowers in advance.
BTW, I'm doing this in Lightspeed Pascal 1.11a on a 2meg MacII running
System 5.0.
_____________________________________________________________________
Sorry, no disclaimer. duggie@Jessica.stanford.edu (Doug Felt) (09/14/88)
After seeing the MacTutor article on CDEF's I decided to see if they were as big a hassle as they seemed. They were. I wrote a 'dial' with a needle that you can drag as the indicator, using LSC. To do the development I called the relevant routines directly, and then packaged the routines using the dispatch routine, then finally created a CODE resource and tested that. Conclusion? Since it was so much easier to use the original package of routines, there was no reason to bother making it a resource! The only reason I can see for writing your own CDEF is to replace one of the existing CDEF's with your own, in order to make cute hacks to other people's applications. In your own applications it is much easier to write a unit or unit-like piece of code to do the drawing and tracking yourself. In other applications just link with that unit. You still have the modularity, and you have the added benefit of knowing exactly what the code is doing. In my experience most of the code is in the CDEF anyway, and the ControlManager calls are easily duplicated. (I have the same feelings about the Dialog Manager... :-) (P.S. since there is no 'sloprect' etc for a needle that pivots, I didn't use those routines obviously designed just for the scrollbar. So I don't know why the original poster's code, which implemented these routines, was getting called the way it was.) If anyone wants the dial CDEF let me know and I will post it. Doug Felt Courseware Authoring Tools Project Sweet Hall 3rd Floor Stanford University Stanford, CA 94305 duggie@jessica.stanford.edu
mnkonar@srcsip.UUCP (Murat N. Konar) (09/15/88)
Doug Felt writes: >The only reason I can see for writing your own CDEF is to replace one >of the existing CDEF's with your own, in order to make cute hacks to >other people's applications. (etc)... It is indeed my wish to make "cute hacks" to other peoples applications. I am trying to implement a variation of Apple's scroll bars. So far I have a scroll bar that does everything Apple's does, but I want to go further. Just doing the scroll bar takes you way past the articles in MacTutor as far as a complete CDEF that makes use of ALL messages. I have learned an awful lot about CDEFs in the process (no surprise), though most of what I learned was by trial and error and NOT from "Inside Macintosh" (no surprise here either, I guess, but we should expect better). As I posted previously, there is only the scantest information out there on the intricacies of CDEFs so if anyone can help me out I'd really appreciate it. Let's break this conspiracy of silence. _____________________________________________________________ Have a day. :'| Murat N. Konar