Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!matthews From: matthews@eleazar.dartmouth.edu (Jim Matthews) Newsgroups: comp.sys.mac.programmer Subject: Re: Problem with LSP glue for SetClikLoop Message-ID: <13197@dartvax.Dartmouth.EDU> Date: 24 Apr 89 15:04:58 GMT References: <13147@dartvax.Dartmouth.EDU> <13148@dartvax.Dartmouth.EDU> <1681@husc6.harvard.edu> Sender: news@dartvax.Dartmouth.EDU Reply-To: matthews@eleazar.dartmouth.edu (Jim Matthews) Organization: Dartmouth College, Hanover, NH Lines: 34 In article <1681@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > [Problems installing a custom TE Click Loop] > > The "LSP Glue" is supplied to us by Apple, so we're pretty much >at their mercy. The bug is that, as you point out, the "SetClikLoop" >glue simply smashes the saved click loop. I apologize to the Think library programmers, and hope Apple's people will fix this. I would suggest that Think leave this glue out the LSP libraries until Apple fixes it. It's deceptive to offer a routine that will fail if you either use it twice or use it with a DA that also calls it. The users whose machines are crashing don't care whose fault it is. > I'm not sure if this is bulletproof, but I assigned the >address of my custom click loop directly to the TEHandle, and it >seems to work OK. This isn't bulletproof. Unlike most call-back routines, click loops have to preserve D2 and set D0 to a non-zero value at exit. Hence the reason for the glue. It's possible to work around the problem with libraries routines that return and set registers. > A more thorough solution might maintain a stack of routines >saved in 14(a5), and a special MySetClikLoop which would push the old >address, save the new. I question the wisdom of using the application parameter space for this kind of kludge. Furthermore this scheme would only allow one current click loop -- you should be able to have a different routine for each text edit record. Jim Matthews Dartmouth Software Development