Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!topaz!uwvax!uwmacc!dubois
From: dubois@uwmacc.UUCP (Paul DuBois)
Newsgroups: net.micro.mac
Subject: Re: Delphi Mac Digest V2 #25 (Re:  TEClick bug)
Message-ID: <16@uwmacc.UUCP>
Date: Mon, 23-Jun-86 10:05:21 EDT
Article-I.D.: uwmacc.16
Posted: Mon Jun 23 10:05:21 1986
Date-Received: Wed, 25-Jun-86 05:22:21 EDT
References: <5199@topaz.RUTGERS.EDU>
Organization: UW-Madison Primate Center
Lines: 87


> 
> From: ASMCOR (9373)
> Subject: teclick?
> Date: 20-JUN 18:43 Programming
>  
> Mike -
> Sent this to Jon, but I wanted to pass it on to you too, just in case you have
> any great ideas about possible incompatibility areas between Megamax and
> Lightspeed -->
>     I've run into a perplexing problem, perhaps you may have some suggestions
> on where I might look for the solution.  I have ported an application over to
> Lightspeed from Megamax.  It is a specialized text editor for the visually
> impaired.  It uses the standard TextEdit routines.The problem is, when compiled
> under Lightspeed, the program crashes when you click in the text window ONLY
> ON A MAC WITH THE OLD ROMS.  It does not do this when compiled under Megamax.
> The call that's causing the crash is TEClick, not exactly an unusual call, and
> I have implemented it in a very simple manner. Here is the section of code
> which causes the crash:
>  
> handle_edit(theW)
> WDescPtr                theW;
> {
>         if(myevent.modifiers & 512)
>                 TEClick(myevent.where,1,theW->hTE);
>         else
>                 TEClick(myevent.where,0,theW->hTE);
> }
>  
>  The parameters on entry seem to be correct, because the program does not crash
> until you release the mouse and TEClick returns.  Then it crashes with an
> address error.
>   Again, let me emphasize that the program runs fine on the Mac+ or 512E.
> I even tried TMON's trap discipline and heap scramble, and I can't get it to
> crash with the new ROMs.  At this point I'm stumped.  My only idea is that
> somewhere prior to this routine the stack is getting messed up,and when TEClick
> tries to return it finds a bad address on the stack. Of course, I COULD go back
> to Megamax and forget it,but I've made quite a few changes to the program since
> I moved it to Lightspeed, and I'd have to try to remember them all and port
> them back.  And I'd have to give up the great Lightspeed system, which is hard
> to do once you get used to it!
>    Any ideas?  Even just general ones might be helpful.
>   Thanks again - Jan.
>  
> Thanks Mike --
> 
> ------------------------------
> 
> From: ASMCOR (9383)
> Subject: I found it
> Date: 21-JUN 00:47 Programming
>  
> Mike -
> I found it. It's weird. I have a simple clickloop routine, and a pointer to it
> is stored in the TERecord's cliKloop field. Naturally it gets called whenever
> TEClick is invoked.  The problem is that I had declared the routine as pascal,
> since it gets called back from the ROM. This works fine with the 128K ROMs, but
> it crashes with 64K ROMs.  Changing it to a normal C function causes it to work
> with both systems.  Why should this be?  Technically, it SHOULD be a pascal
> function, right?
> 
> Jan 
> 
> p.s. This happens even if the clickloop routine is nothing but a stub,
> i.e.  two braces with nothing in between.  If it's pascal, it crashes,
> if it's not, it works.


Declaring a routine as "pascal" may not be enough.

I had similar problems using a filter function to track clicks in a
scroll bar.  My problem was that I was declaring my function as

	pascal filterproc ()

rather than

	pascal void filterproc ()

which did the trick.

-- 
Paul DuBois     UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois    |
                ARPA: dubois@easter                               --+--
                                                                    |
"Well, we can't give an award to a _dead_ pig," said                |
the loud speaker.  "It's never been done."