Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!mailrus!sharkey!oxtrap!time From: time@oxtrap.sendai.ann-arbor.mi.us (Tim Endres) Newsgroups: comp.sys.mac.programmer Subject: Re: DA loses resource file on accRun Message-ID: Date: 19 Jul 89 18:37:26 GMT References: <1989Jul17.045641.20314@lth.se> Sender: time@oxtrap.UUCP Reply-To: time@oxtrap.UUCP Organization: Digital Works, Ltd. - Ann Arbor, MI Lines: 59 In-reply-to: sund@tde.lth.se's message of 17 Jul 89 04:56:41 GMT In article <1989Jul17.045641.20314@lth.se> sund@tde.lth.se (Lars Sundstr|m) writes: I'm developing a desk accessory which reads a resource file continuously. When the DA is running as a foreground task it periodically receives accCursor events which is used for reading a couple of resources. So far so good. However when running in the background the DA only receives accRun events and the DA can't reach the resource file because UseResFile(myResFile) gives ResError=-193 "resource file not found". It seems to me that when the DA receives accRun events its called without a context switching but I don't know for sure. Does anyone know what's the problem here? Assuming you are under MultiFinder... You do not mention where myResFile came from, but lets assume for the moment that you open it in the DA w/ OpenResFile(). The difference between accCursor and accRun is that accCursor *only* happens when the DA Manager is active. accRun, on the other hand, can come any the time. Now, I do know that the opened resource file gets a table entry in the FCB table. And that this is NOT ties to the running application. So, unless someone is closing that file, it should still be valid. The only possibilities for it to not be valid are: 1) Your "myResFile" is wrong. I assume you checked this. 2) The file somehow got closed. Difficult to check (walk the FCB table by hand), but I assume this is not the problem. 3) The resource file chain does not include myResFile I have to beleive, that for sanity reasons, MultiFinder keeps seperate chains of resource files. I would think this in that many applications depend on a "well defined" resource chain. I.e. I expect that the resource I am asking for will come from my application's resource fork, and not some other's. If this is the case, then I would tend to beleive that you have two different resource file chains, the one you get in the foreground, and the one you get in the background. Thus, accRun gets a chain without the file that you are looking for. The fix: * Migrate the resources to the system file. * Keep resources in memory. I assume you can't, thus the reason for the problem. * Open and Close the resource file around the reads. Boy, here's a performance beast. * Don't use resources. Use an open file and struct's. BTW: I would use accRun for ALL cases. accCursor is very unreliable for periodic action, and too much overhead when the cursor is flying about the DA's window. Of course, you may have very good interface reasons for this approach. So, this was a lot of rambling. Hope it contains a good pointer. Tim.