es2q+@andrew.cmu.edu (Erik Warren Selberg) (12/13/89)
ok... I finally fixed the clicking bug (by SetPorting every time I checked if the application was mine (& thus did something with it). Now for the new improved yell: I'd like to put the data object I have (called TFile, an object with a bunch of neat stuff contained) into the list instead of using up 100 bytes a shot as I am now... I've tried putting it in using StripAddress, putting in the starting file (well, a pointer to the starting file) in the list's refCon and trying to access it from there, and nothing. Is there any way to access variables in the main program from an LDEF, and if so, how??! what am I doing wrong? also: is there any way to debug an LDEF (or any code resource) from LSP? this trial & error stuff is rather depressing! ------------------/ Megalo Erik \-------------------- GEnie: E.SELBERG | Selberg | CIS: 71470,2127 Delphi: LORDERIK | lost in | Fido: 129/107 BBS: 412 268 8974 | Andrew! | MacList: 6009/1 ------------------\ help! help! /-------------------- ...I'm being confused at CMU!
amanda@mermaid.intercon.com (Amanda Walker) (12/14/89)
In article <cZVSJ9i00WB2Q63mcX@andrew.cmu.edu>, es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: > Is there any way to access > variables in the main program from an LDEF, and if so, how??! Well, they way I do it is to have a baby LDEF that, by default, just draws a string they way LDEF 0 does, but if the list's refCon is non-zero, treats it as a pointer to a function and calls it to do the drawing. All you have to do is make sure A5 is set correctly. Here's the source for the LDEF in MPW C 3.0, taken in its entirety from known working code. It does contain "the cast from Hell," but hey :-). ---------------------- /* Simple Custom LDEF Amanda Walker, InterCon Corporation 6 October 1988 This is a very simple custom LDEF. It acts just like LDEF 0 if the refCon field of the list is 0. If it is non-zero, the LDEF treats it as the address of a routine to call to actually draw a list element. */ #include <Quickdraw.h> #include <Lists.h> #include <OSUtils.h> #define nil ((void *) 0L) pascal void STUBLDEF(lMessage, lSelect, lRect, lCell, lDataOffset, lDataLen, lHandle) short lMessage; Boolean lSelect; Rect *lRect; Cell *lCell; short lDataOffset, lDataLen; ListHandle lHandle; { char *p; long savedA5; /* Make sure A5 is valid so the draw code can use its globals. */ savedA5 = SetCurrentA5(); p = (char *) 0x938; /* HiliteMode for color QD */ lMessage--; /* no initialization */ if (!lMessage--) { /* draw the cell */ if ((**lHandle).refCon) (*((pascal void (*)(Rect *, Cell *, short, short, ListHandle)) (**lHandle).refCon))(lRect, lCell, lDataOffset, lDataLen, lHandle); else { MoveTo(lRect->left + 5, lRect->top + 12); HLock((**lHandle).cells); DrawText(*((**lHandle).cells), lDataOffset, lDataLen); HUnlock((**lHandle).cells); } if (lSelect) { *p = *p & 0x7f; InvertRect(lRect); } } else if (!lMessage--) { /* toggle highlighting */ *p = *p & 0x7f; InvertRect(lRect); } SetA5(savedA5); /* no closing code */ } ---------------------- If you don't know how to build code resources with MPW C, take a look at the examples in the CExamples directory. Hope this helps, Amanda Walker InterCon Systems Corporation --
trebor@biar.UUCP (Robert J Woodhead) (12/14/89)
es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >Is there any way to access >variables in the main program from an LDEF, and if so, how??! what am I doing >wrong? Basically, you need to set things up in your LDEF so that your "A5" world is correct. TN256 should point you in the right direction. -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP Announcing TEMPORAL EXPRESS. For only $999,999.95 (per page), your message will be carefully stored, then sent back in time as soon as technologically possible. TEMEX - when it absolutely, postively has to be there yesterday!
tim@hoptoad.uucp (Tim Maroney) (12/15/89)
In article <cZVSJ9i00WB2Q63mcX@andrew.cmu.edu> es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >ok... I finally fixed the clicking bug (by SetPorting every time I checked >if the application was mine (& thus did something with it). Great, send me a million dollars now. >I'd like to put the data object I have (called TFile, an object with a bunch >of neat stuff contained) into the list instead of using up 100 bytes a shot >as I am now... I've tried putting it in using StripAddress, putting in the >starting file (well, a pointer to the starting file) in the list's refCon and >trying to access it from there, and nothing. Is there any way to access >variables in the main program from an LDEF, and if so, how??! what am I doing >wrong? I don't know; once again, your report has been far too vague to allow any solid deductions or even founded speculations. "And nothing" is no more a report of a symptom that is "I don't feel so hot". You can store common data structures in the list's refCon or in the list's userHandle. These are then accessible by the LDEF through the list handle it is passed, and by the application through the list handle it is keeping track of. What's the problem? Does the refCon come out as zero or some other invalid value in the LDEF? Then you're not stashing the value correctly. The syntax would be "list^^.refCon = LONGINT(<whatever>);" if I remember my Pascal. >also: is there any way to debug an LDEF (or any code resource) from LSP? >this trial & error stuff is rather depressing! Lots of ways. First, to debug on the Mac, you simply must learn a low level debugger, such as MacsBug or TMON. You can debug anything this way. David Oster just gave a description of the process. Briefly, place a Debugger instruction (0xa9ff) in your code at the point where you want to start watching the fun, and then step through. It helps to have a paper listing of your program so you can follow along better. You can also track the general flow of execution in various other ways. If you're not sure a piece of code is getting executed, put a SysBeep in it. And so on. If you simply can't live without a symbolic debugger, then you use a pass-through code resource. Your actual LDEF resource is six bytes, starting with the word for a JMP.L instruction with an absolute long operand (0x4ef9), and having the address of your definition procedure in the second and third words. You link the definition procedure (the LDEF code) with your application, and set up the six-byte LDEF resource with the address of the main LDEF routine before you create your list, making sure it's non-purgeable so it won't get refeshed from disk. Then you can put symbolic breakpoints in your LDEF to your heart's content. After it's debugged sufficiently, you can make it a real, separate LDEF again if you wish -- or you can leave it the way it is. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd
tim@hoptoad.uucp (Tim Maroney) (12/16/89)
es2q+@andrew.cmu.edu (Erik Warren Selberg) writes: >>Is there any way to access >>variables in the main program from an LDEF, and if so, how??! what am I doing >>wrong? In article <977@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >Basically, you need to set things up in your LDEF so that your "A5" world >is correct. TN256 should point you in the right direction. Not really. There's no way to make the linker generate the correct A5 offsets in a separate code resource. It generates these when creating the application code resources, but even if you can extract them from the location map, there's no way to tell the linker to use the same offsets when generating the LDEF resource. Either putting shared data structures in the refCon or faking out the LDEF to actually be part of your program (I suggested one way, Amanda another) is the way to go. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Feminism that refuses to use the word "patriarchy" is kin to abolitionism that refuses to use the word "slavery".