chaffee@uvm-gen.UUCP (Alex D. Chaffee) (04/15/89)
Help! All I did was open a resource file with the following call OpenRFPerm(fName, vRefNum, (SignedByte)fsRdWrPerm); and my resources got mangled. After the call, my Alerts show all the signs of being handles to nowhere (i.e. they seem to be appearing off-screen, they beep occasionally...). fName and vRefNum come straight from SFGetFile's reply record, and there are no ALRTs in the file I opened... Can anybody remember when _they_ were inexperienced and ran into something like this? Thanks, Alex Chaffee chaffee@uvm-gen.uvm.edu -- Alex Chaffee chaffee@uvm-gen.uvm.edu Disclaimer: The ideas expressed above were implanted in my brain by Martians -----
tim@hoptoad.uucp (Tim Maroney) (04/17/89)
In article <1146@uvm-gen.UUCP> chaffee@uvm-gen.UUCP (Alex D. Chaffee) writes: >Help! All I did was open a resource file with the following call > OpenRFPerm(fName, vRefNum, (SignedByte)fsRdWrPerm); >and my resources got mangled. After the call, my Alerts show all the >signs of being handles to nowhere (i.e. they seem to be appearing off-screen, >they beep occasionally...). >fName and vRefNum come straight from SFGetFile's reply record, and there >are no ALRTs in the file I opened... Can anybody remember when _they_ >were inexperienced and ran into something like this? I don't remember running into anything like this. However, one explanation that springs to mind and seems to fit the facts is that you opened a corrupt resource file. Having a corrupt file as the first file in the list could easily perturb all resource searches. One way to check this would be to open it, then UseResFile on your application file to take the newly opened file out of the picture. If things then work OK, my guess would be fairly well confirmed. Another way, if you're using MPW, would be to use RezDet on the file that causes the problems. Other useful debugging information would come from opening a variety of files and seeing if they all cause the same symptoms; if so, the problem is in your code somewhere. You'll find that if you post code, there's no lack of people here able and willing to find flaws in it.... One final idea: the resource file you opened may include DITLs that conflict with yours even though there are no ALRTs. In general, it is not at all safe to open other resource files and leave them open as you're running, since your code depends on seeing resources that look a certain way with a certain number. The potential for conflicts is enormous. If you must open other resource files that are not owned by you, don't leave them open in the resource search path. Either UseResFile to take them out of the picture, or close them as soon as you're done and before going back to your main event loop. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The pride of the peacock is the glory of God. The lust of the goat is the bounty of God. The wrath of the lion is the wisdom of God. The nakedness of woman is the work of God." - Blake, "The Marriage of Heaven and Hell"
russotto@wam.UMD.EDU (04/18/89)
In article <1146@uvm-gen.UUCP> chaffee@uvm-gen.UUCP (Alex D. Chaffee) writes: >Help! All I did was open a resource file with the following call > OpenRFPerm(fName, vRefNum, (SignedByte)fsRdWrPerm); >and my resources got mangled. After the call, my Alerts show all the >signs of being handles to nowhere (i.e. they seem to be appearing off-screen, >they beep occasionally...). >fName and vRefNum come straight from SFGetFile's reply record, and there >are no ALRTs in the file I opened... Can anybody remember when _they_ >were inexperienced and ran into something like this? > >Thanks, >Alex Chaffee >chaffee@uvm-gen.uvm.edu > >-- >Alex Chaffee >chaffee@uvm-gen.uvm.edu >Disclaimer: The ideas expressed above were implanted in my brain by Martians >----- Is this MPW C? In MPW 2.0.x, at least, you need to call p2cstr(&fName); and then make the call using the pointer, i.e.: OpenRFPerm(&fName, vRefNum, (SignedByte)fsRdWrPerm); -- Matthew T. Russotto russotto@wam.umd.edu <insert witty expression here>
chaffee@uvm-gen.UUCP (Alex D. Chaffee) (04/22/89)
Tim, your intuition seems to be correct. Although I haven't _quite_ finished debugging the whole program, it is obvious that the problem lies with certain, apparently corrupt, resource files. (For those of you who've just joined us: When I opened the resource fork of a file with OpenRFPerm directly following an SFGetFile, my resource map got trashed, as evidenced by Alerts appearing off-screen and so forth.) I now have two questions: 1) ResEdit opens these files (there are two) fine, and the FKEYs within them work fine when installed into the system. What can be special about them? 2) How can I programmatically detect and/or correct this user-nasty situation? Or any similar situation where the Resource Manager gets confused... Is there an error-reporting function or global? I seem to remember catching the end of a related thread on the net a week or two ago. Thanks for any assistance or ideas.
tim@hoptoad.uucp (Tim Maroney) (04/26/89)
In article <1152@uvm-gen.UUCP> chaffee@uvm-gen.UUCP (Alex D. Chaffee) writes: >Tim, your intuition seems to be correct. Although I haven't _quite_ >finished debugging the whole program, it is obvious that the problem lies >with certain, apparently corrupt, resource files. Well, it's not certain yet (see below). >(For those of you who've just joined us: When I opened the resource fork of > a file with OpenRFPerm directly following an SFGetFile, my resource map > got trashed, as evidenced by Alerts appearing off-screen and so forth.) > >I now have two questions: > >1) ResEdit opens these files (there are two) fine, and the FKEYs within > them work fine when installed into the system. What can be special > about them? I don't know how much special checking ResEdit does. (Jon?) If I wonder about the correctness of a file, I go into MPW and run the RezDet tool on it. This picks up and reports on a wide variety of resource file problems. ResEdit bypasses the Resource Manager and handles the resource file format directly, so it is possible that there could be an error that wouldn't make ResEdit choke but would make the RM freak out. I have to say it seems a bit unlikely. >2) How can I programmatically detect and/or correct this user-nasty > situation? Or any similar situation where the Resource Manager gets > confused... Is there an error-reporting function or global? I seem > to remember catching the end of a related thread on the net a week or > two ago. In practice, I don't think any developers actually check their resource files except for the few that bypass the resource manager completely. Remember, though, the real problem is that if you let users open any resource files that aren't owned by you, you can't guarantee that its resources won't conflict with yours, and you shouldn't keep it in the resource search path except during the rare times when you're extracting information from it and changing information in it. I still tend to suspect that you may have some such conflict situation here. Could you describe in a bit more detail why you are opening the resource files? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The above opinions and suggestions have absolutely nothing to do with the little, fat man putting crisp, $100 bills in my pocket." -- Alan Vymetalik
lsr@Apple.COM (Larry Rosenstein) (04/26/89)
In article <7087@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > >1) ResEdit opens these files (there are two) fine, and the FKEYs within > > them work fine when installed into the system. What can be special > > about them? > > I don't know how much special checking ResEdit does. (Jon?) If I > wonder about the correctness of a file, I go into MPW and run the > RezDet tool on it. This picks up and reports on a wide variety of > resource file problems. ResEdit bypasses the Resource Manager and > handles the resource file format directly, so it is possible that ResEdit does use the Resource Manager. (It may do some additional checking, I don't know.) I broke in Macsbug on OpenResFile and Get1Resource, and ResEdit called both of them. One thing ResEdit does do is control which resource file is current, etc. As Tim said, this is VERY important if your program opens arbitrary resource files. For example, suppose you open an application, and try to call a procedure in a different segment. Unless you are careful, you will get the segment out of the data file, and not your application. Now the report above says that ResEdit can not only open the problem resource files, but also can manipulate the resources contained within. This would seem to rule out the explanation that the resource files were corrupted. In that case, I would look at the possibility that the resource files contain some resources that are conflicting with the application. They might be CODE resources, DLOG, etc. Also, look and see if the problem resource fils have any resources marked preload. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
tim@hoptoad.uucp (Tim Maroney) (05/08/89)
>In article <7087@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > I don't know how much special checking ResEdit does. (Jon?) If I > wonder about the correctness of a file, I go into MPW and run the > RezDet tool on it. This picks up and reports on a wide variety of > resource file problems. ResEdit bypasses the Resource Manager and > handles the resource file format directly, so it is possible that In article <1542@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >ResEdit does use the Resource Manager. (It may do some additional >checking, I don't know.) I broke in Macsbug on OpenResFile and >Get1Resource, and ResEdit called both of them. Sorry for the misinformation. My friend Tracy spent some time talking with DTS about this a few years ago, and at the time, he was informed that ResEdit does not use the Resource Manager. Either that was a mistake then, or the code has changed. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The Diabolonian position is new to the London playgoer of today, but not to lovers of serious literature. From Prometheus to the Wagnerian Siegfried, some enemy of the gods, unterrified champion of those oppressed by them, has always towered among the heroes of the loftiest poetry." - Shaw, "On Diabolonian Ethics"