earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/30/89)
In article <13197@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes: >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. SetWordBreak does the same kind of thing, but uses $18(A5) instead of $14(A5). I am assuming that you that you use glue related to what comes with MPW 3.0 in {Libraries}Interface.o. Notice that Apple also supplies dumpobj, so you are not completely at their mercy. >> 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. > This is the scheme described in the "Promotional Edition," or "Phonebook" edition of Inside Macintosh. There are also described "AsmClikLoop" and "AsmWordBreak" routines to call your custom routines, assuming these are called "PasClikLoop" and "PasWordBreak." Note that these have the problem that only one custom clikLoop or wordBreak may be assigned per link, unless you provide the glue to fix up the registers yourself. In any case, the original scheme, where the addresses of the clikLoop and wordBreak routines go into the TEHandle, is the best, assuming you fix up the registers as necessary. The calling sequence for a clikLoop function is identical to that for a C function, providing that the compiler preserves D2. C returns the result code of the function in D0. If your compiler lets you declare your function as having a C prototype, then declare the clikLoop function as C, and cause it to return true. You could also declare your clikLoop function as a Pascal Procedure with no parameters, and have it set D0 to a non-zero value before it returns. A way to set D0.W to 1 might be to use an inline opcode of $7001 (MOVEQ #1,D0). Saving/restoring D2 should be pretty easy, too. Note that if your clikLoop is declared as Pascal Boolean, and is being called directly from TextEdit, then it is putting its return value somewhere strange. I have no problems with clikLoop functions written in MPW C, and with their addresses stored directly in the proper field of the TERec. >> 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 is right. The Apple glue is bogus. It can only be called once per running application, and calling it from a desk accessory is a real risky thing to do. Setting up the registers to be called properly from TextEdit is easy, so do it that way, and store the address of your wordBreak/clikLoop routine directly in the TERec. Referring to the map of application parameter space, Figure 1. on page 4 of the Segment Loader chapter of the PhoneBook, I see that the locations at $14(A5) and $18(A5) are part of an area marked "reserved for future use." It appears that Apple is fully justified in using this area of memory for anything they like. Why they would choose to use it for such a purpose, AND implement it incorrectly, is beyond my comprehension. Earle R. Horton Graduate Student. Programmer. God to my cats.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/30/89)
In article <13197@dartvax.Dartmouth.EDU>matthews@eleazar.dartmouth.edu (Jim Matthews) writes: >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. After another use of dumpobj, I see that {CLibraries}CInterface.o as supplied with MPW C v 2.0.2 also uses the same questionable scheme to implement SetWordBreak and SetClikLoop. Since the Pascal glue for MPW 3.0 does this, I would assume that the 3.0 C glue still does, too. My personal recommendation is not to use any SetWordBreak or SetClikLoop glue from Apple at this time. Aztec C 3.6c does not supply glue for these routines, but rather uses macros which install pointers to your routines directly in the TERec. They also supply information on writing these custom routines correctly. Apparently, not all compiler writers are so much at the mercy of Apple. Earle R. Horton Graduate Student. Programmer. God to my cats.