Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!mcnc!ncsuvx!news
From: hench@csclea.ncsu.edu (Steven Hench)
Newsgroups: comp.sys.mac.programmer
Subject: Re: TrackControl(), contrlAction, and all that jazz
Summary: pascal keyword and callback routines
Message-ID: <1990May8.004637.5540@ncsuvx.ncsu.edu>
Date: 8 May 90 00:46:37 GMT
References: <621@fornax.UUCP>
Reply-To: hench@csclea.UUCP (Stephen D. Hench)
Distribution: na
Organization: NCSU Computing Center
Lines: 37

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!  :)