rob@cs.mu.oz.au (Robert Wallen) (09/25/89)
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'? I have a couple of custom-CDEFs I have been working on which use autotrak routines. Ref: Inside Macintosh I-323, The Control Manager, "Mouse Location" "When the mouse button is released TrackControl returns with the part code if the mouse is in the same part of the control that it was originally in, or with 0 if not (in which case the application should do nothing)" Now, when I call TrackControl() with my control, I see it hilite (sic) correctly when the mouse is moved in/out of it but TrackControl ALWAYS returns the 'inButton' code that the first call to TestControl() within TrackControl() (yes, I can drive TMON) returned. My CDEF is returning 'inbutton/zero' correctly but TrackControl() seems to be ignoring it. Its not clear from Inside Mac whether the autotrack message should actually return a value anyway; MacNosy would appear to say Nope. Should TrackControl() be returning zero if the mouse was released outside the active area, or should my caller just ignore TrackControl's return value? Thanx in advance, Rob -------------- "I meant," said Ipslore, bitterly, "what is there in this world that makes living worth while?" Death thought about it. CATS, he said eventually, CATS ARE NICE. -- Sourcery, Terry Pratchett
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (09/26/89)
In article <2838@murtoa.cs.mu.oz.au> rob@cs.mu.oz.au (Robert Wallen) writes: >I have a couple of custom-CDEFs I have been working on which use autotrak >routines. [edited for length] >Now, when I call TrackControl() with my control, I see it hilite (sic) >correctly when the mouse is moved in/out of it but TrackControl ALWAYS >returns the 'inButton' code that the first call to TestControl() within >TrackControl() (yes, I can drive TMON) returned. My CDEF is returning >'inbutton/zero' correctly but TrackControl() seems to be ignoring >it. Its not clear from Inside Mac whether the autotrack message should >actually return a value anyway; MacNosy would appear to say Nope. > >Should TrackControl() be returning zero if the mouse was released outside >the active area, or should my caller just ignore TrackControl's return value? Let's see. I think I understand what your problem seems to be. If the following makes no sense, please try to clarify the problem. Here goes: TrackControl will return 0 if you release the mouse button outside of the part you started in. If the part is an indicator (like the thumb of the standard scroll bar), TrackControl will also return zero if you move the thumb but move it back before you release it, even though you released the mouse button in the same part you started in. Perhaps you are having problems based on this phenomenon. The reason for this could be so that a window need not be updated if the control value has not changed (this is the only rationalization I can come up with). I don't have my code or IM volumes handy so this is about all the explanation I can give with a degree of certainty. Check to see if the partcode your CDEF is returning is the one for an indicator (254, I think). I bet this is your problem. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
rob@cs.mu.oz.au (Robert Wallen) (09/27/89)
In <32458@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes: > In <something or other> I wrote ..... [ about custom CDEFS and autotracking] >>Should TrackControl() be returning zero if the mouse was released outside >>the active area, or should my caller just ignore TrackControl's return value? > >Let's see. I think I understand what your problem seems to be. If >the following makes no sense, please try to clarify the problem. > >TrackControl will return 0 if you release the mouse button outside of >the part you started in. If the part is an indicator (like the thumb Nope. It returns inButton even if I release the mouse outside the control. >the explanation I can give with a degree of certainty. Check >to see if the partcode your CDEF is returning is the one for >an indicator (254, I think). I bet this is your problem. Nope. inButton. Nice try though. Anyone else got any ideas? Thanx for answering, Rob -------------- "I meant," said Ipslore, bitterly, "what is there in this world that makes living worth while?" Death thought about it. CATS, he said eventually, CATS ARE NICE. -- Sourcery, Terry Pratchett
tecot@Apple.COM (Ed Tecot) (10/04/89)
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
wdh@well.UUCP (Bill Hofmann) (10/05/89)
In article <35247@apple.Apple.COM> tecot@Apple.COM (Ed Tecot) writes: >The 10/89 revision of Technical Note #196, 'CDEF' Parameters and Bugs >addresses this issue. Basically, Inside Macintosh is wrong on several counts. On a side issue, I recall some traffic a while back from Apple requesting comments about Inside Mac. While it quickly degenerated into a fight about binding (loose leaf or ...), I do recall wondering if Apple was ever going to do at least a bug-fix update, and maybe integrate (say) the IM-IV File Manager chapter with the IM-II one. Any comments from Apple? -Bill
mcdonald@fornax.UUCP (Ken Mcdonald) (05/07/90)
I'd really appreciate some help from people in the know...(relative to
me, that qualifies most of the net to answer)...
I'm writing some code in THINK C to help out with dialog stuff. One
of the things it does is create controls at run-time (no, it doesn't
read 'em from a resource file, it creates them out of thin air. Don't
ask why, I have my reasons). One of these controls is intended to perform
the function of a popup menu. Sadly, I can't get it to work, and here's
why it's so confusing...
As I understand it, ModalDialog will detect hits on custom controls (using
their contrlDefProc), and then call TrackControl. The chapter on the
dialog manager didn't say much about this, so I'm kinda fuzzy. Now, Track
Control() has three possibilities for running custom code; it can be
passed a pointer to a piece of code (which I can't do, since the dialog
manager is activating TrackControl), it can find a pointer to custom code
in the control's contrlAction field, or it can call the controls contrlDefProc
with a value indicating the control is being activated. As I say, I have
no control over what's passed to TrackControl (the dialog manager does
call TrackControl, right?), but assume it's -1, which means that TrackControl
then looks in my control's contrlAction field; I've set this to -1, which
means that TrackControl should call the control's contrlDefProc, which is
what I want, 'cause that's where the appropriate code is. In fact, this
code does get called, but doesn't evaluate properly (the big bomb). So,
I set a breakpoint in THINK C to determine the problem; surprise, things
are so screwed up by the time I hit the breakpoint (which is set as early
as possible) that just trying to find the value of a local variable (from
the debugger) causes a bus error. Even more confusingly, later runs done
without changing any code cause a bomb even before my breakpoint is
encountered.
So now the questions. The obvious one is, what's wrong, but I find it
unlikely that anyone is going to be able to tell me off the top of my
(oops, their) head. More generally, is my understanding of the way
the dialog manager handles hits on custom controls correct? In all my
wanderings through that chapter, I couldn't find anything that said, "and
THIS is what the dialog manager calls when it detects a hit on your control,
so THIS is where you should put your code for handling it." Also, why
so many opportunities to give TrackControl some custom code. One chance
is necessary, three seems gratuitous.
Arghhhh!!!!!!
(But thanks in advance)
yours confusedly,
Ken McDonald
{mcdonald@cs.sfu.ca}hench@csclea.ncsu.edu (Steven Hench) (05/08/90)
In article <621@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: > [lines trimmed] > ... TrackControl should call the control's contrlDefProc, which is >what I want, 'cause that's where the appropriate code is. In fact, this >code does get called, but doesn't evaluate properly (the big bomb). So, >I set a breakpoint in THINK C to determine the problem; surprise, things >are so screwed up by the time I hit the breakpoint (which is set as early >as possible) that just trying to find the value of a local variable (from >the debugger) causes a bus error. Even more confusingly, later runs done >without changing any code cause a bomb even before my breakpoint is >encountered. > [lines trimmed] > >Ken McDonald >{mcdonald@cs.sfu.ca} Is your control definition function defined with the "pascal" keyword? When TrackControl calls your cntrlDefProc, the Pascal calling conventions are used. If you don't have the keyword, the function is set up assuming the parameters are placed on the stack using the C calling conventions, and once the call is made things are never again quite right. Here's an example from the Think C User's Manual for setting up a filterProc for ModalDialog() to call (v3.0, p.119): pascal Boolean MyFilter(theDialog, theEvent, itemHit) DialogPtr theDialog; EventRecord *theEvent; int *itemHit; If a missing "pascal" isn't the problem, I'm as lost as you are. Stephen D. Hench hench@csclea.ncsu.edu Go Tarheels! :)