Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: List Bummers Revisited Message-ID: <9291@hoptoad.uucp> Date: 14 Dec 89 21:44:18 GMT References: Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 56 In article 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();" 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