Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!ftp!poopsie!bootsie!olson
From: olson@bootsie.UUCP (Eric Olson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Have you had problems with SetClikLoop?
Message-ID: <4@bootsie.UUCP>
Date: 29 Dec 89 23:22:19 GMT
References: <921@excelan.COM> <3429@hub.UUCP> <3509@husc6.harvard.edu>
Reply-To: olson@bootsie.UUCP (Eric Olson)
Organization: Lexington Software Design, Lexington, MA
Lines: 31

In article <3509@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>>From article <921@excelan.COM>, by mahboud@kinetics.com (Mahboud Zabetian):
>>> Hi.  Anybody out there ever try calling SetClikLoop twice consecutively for
>>> different TEHandles?  I am doing so and it seems that the second call also
>>> changes the value of the clikLoop field of the first TE!  Sound strange?

>	SetClikLoop saves away the old clickLoop in a place relative to
>A5, so that it can restore it. When and why, I don't know. Because TE
>doesn't maintain a stack of saved clikLoops, it will smash old ones,
>as you're finding out.
>

When I bumped into this problem, I thought it was a misfeature of Think C.
It seemed to me that the Think C routine for SetClikLoop would always set the
clikLoop field in the TERec to a Think C glue routine, after saving the
actual (pascal) function pointer away in a global.  The glue routine then
translates registers to pascal stack and calls the routine you specified.

Since only one global existed and all TERecs got a pointer to the glue routine,
only the last installed glue routine would ever get executed.

Is this _not_ the case?!?!?  I was pretty sure...

-Eric

P.S.  Of course, the workaround is to set the field directly and use one's
own glue routine, one per ClikLoop function, as amply described by others
who responded.

-- 
Eric K. Olson            olson@endor.harvard.edu          harvard!endor!olson