matthews@eleazar.dartmouth.edu (Jim Matthews) (04/21/89)
version 2.0p1. It seems that when I call SetClikLoop to install a TextEdit click-loop routine the glue for that routine puts TextEdit click-loop routine the address of my routine is placed at 14(A5), in the middle of the application parameters area. That's strange enough, but it got worse for a user of mine who also uses SmartScrap, a souped-up scrapbook DA from Solutions, Inc. When you click on the SmartScrap window it calls an identical glue routine which also stores an address at 14(A5). With my address overwritten the next click on my window causes a crash. I tested one of my own desk accessories written in LSP and it does the same thing. Why does the LSP glue use a strange, fixed location for this? Not only Why does the LSP glue use a strange, fixed location for that purpose? Not only is it guaranteed to cause trouble with DAs that use the same glue, but it will also screw up a program that has multiple different click-loop routines. 30D1 Jim Matthews Dartmouth Software Development M30,30 M30,30 30@1
matthews@eleazar.dartmouth.edu (Jim Matthews) (04/21/89)
Sorry about the previous post -- I forgot that our distributed editor was having some trouble these days.... A program of mine is having trouble with the glue in Lightspeed Pascal version 2.0p1. It seems that when I call SetClikLoop to install a TextEdit click-loop routine the address of my routine is placed at 14(A5), in the middle of the application parameters area. That's strange enough, but it got worse for a user of mine who also uses SmartScrap, a souped-up scrapbook DA from Solutions, Inc. When you click on the SmartScrap window it calls an identical glue routine which also stores an address at 14(A5). With my address overwritten the next click on my window causes a crash. I tested one of my own desk accessories written in LSP and it does the same thing. Why does the LSP glue use a strange, fixed location for that purpose? Not only is it guaranteed to cause trouble with DAs that use the same glue, but it will also screw up a program that has multiple different click-loop routines. Jim Matthews Dartmouth Software Development
siegel@endor.harvard.edu (Rich Siegel) (04/24/89)
In article <13148@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) 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'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. 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. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
matthews@eleazar.dartmouth.edu (Jim Matthews) (04/24/89)
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
Marriott1@AppleLink.Apple.Com (Greggy) (04/25/89)
In article <13197@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes: > 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 This isn't quite true, although that's what IM v4 says. The list manager code branches based on the state of the zero flag when the clikproc returns. This means that the very last action the clikproc takes must clear the zero flag. Setting D0 to a non-zero value works, but only if no other instructions mess with the zero flag before returning. (I spent many long hours tracking this down!) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Greg Marriott + AppleLink: Marriott1 + + Just Some Guy + + + "My phone is always busy" + Internet: Marriott1@AppleLink.Apple.Com + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Just in case disclaimers mean anything at all: + + What I say comes from my own twisted perception of the world + + and does not represent the policy or opinion of Apple Computer, Inc. + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++