Path: utzoo!attcan!ncrcan!becker!censor!comspec!tvcent!lethe!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!van-bc!ubc-cs!fornax!mcdonald
From: mcdonald@fornax.UUCP (Ken Mcdonald)
Newsgroups: comp.sys.mac.programmer
Subject: TrackControl(), contrlAction, and all that jazz
Keywords: Boy, am I kerflummoxed.
Message-ID: <621@fornax.UUCP>
Date: 7 May 90 03:35:23 GMT
Distribution: na
Organization: School of Computing Science, SFU, Burnaby, B.C. Canada
Lines: 47

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}