payne@unocss.UUCP (Matt Payne) (08/22/89)
Please forgive the naive question but I would like to do this: Can a program be made to alter its own resource fork? Toward the purpose of chaning where windows come up on the screen when they are first brought up, etc. I've just started programming in MPW C. It seems to me that this would be a "nice" feature for a program to have. If it turns out that it would not be a nice feature to have please enlighten me. BTW: Here's yet another "standard" request for good book lists, and ftp cites that contain C source code (for MPW C), and archives of this group. Thanks!!! - matt -- Matt Payne Internet:conslt10@zeus.unl.edu UUCP:uunet!btni!unocss!payne Bitnet:CONSLT10@UNOMA1
d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) (08/22/89)
In article <1492@unocss.UUCP> payne@unocss.UUCP (Matt Payne) writes: >Can a program be made to alter its own resource fork? Toward the >purpose of chaning where windows come up on the screen when they >are first brought up, etc. It is a good idea to save away data for your windows location etc. This is actually endorsed by Apple Computer (TM, Inc) and described in a TechNote. This TechNote tells you to save away such data ("Preferences") in a file, preferrably in the startup system folder. The VRefNum of this folder is available from the SysEnvirons call. You should NOT change the resource frok of the program, since it will then not be sharable over networks. Apple has carefully instructed us in treating the resource fork as "read only" (Which means that it may eventually actually be that way .-|) So get on with designing a "stationery ICN#" and saving your prefs in the system folder. The resource fork of THIS file you can modify as much as you like, since (hopefully) you'll only run one app of the same type using any one startup system. If you want to be * REALLY * paranoid, you could name the prefs file after the Applications name (not har-code it) thus making it possible to use more than one copies of the same app at the same time on the same machine. (Ungh. Is there a -v option (non-verbose) on me ?? ,-) Happy hacking! h+@nada.kth.se -- This is your fortune from h+@nada.kth.se: You cannot achieve the impossible without attempting the absurd.
hoffman@ux1.cso.uiuc.edu (08/28/89)
I've been doing that for years. I think I read somewhere that you should
never change the resources of the running program, but I've NEVER had a
problem.
What I do is create a resource called PREF for my preferences. ID can be
anything but I start at 0. I do a GetResource("PREF",0) and if NIL is
returned then you create a default resource and write it. Then when you
quit your program, call ChangedResource followed by WriteResource. You
can find all of this in IM vol. 1 chapter 5. As for the data type of
a PREF. It's whatever you want:
myPrefHandle=^myPrefPtr;
myPrefPtr=^myPrefRec;
myPrefRec=RECORD
.. your fields here ..
end; (* record *)
It's really a neat thing, but do some checking after GetResource in case
someone has been poking around with ResEdit where they shouldn't. If you get
back an invalid PREF, just go back to the default.
Steve
___________________________________________________________________
| Steve M. Hoffman | email: hoffman@ux1.cso.uiuc.edu |
| University of Illinois | internet: hoffman%ux1@uxc.cso.uiuc.edu |
| Champaign/Urbana | uucp: uunet!uiucuxc!ux1!hoffman |
|________________________| usmail: 515 Bach Ct. #24 |
| I haven't a clue what | Champaign, IL 61820 |
| I'm doing here | (217)/359-7448 |
|________________________|________________________________________|blm@6sigma.UUCP (Brian Matthews) (08/28/89)
In article <18300004@ux1.cso.uiuc.edu> hoffman@ux1.cso.uiuc.edu writes: |I've been doing that for years [an application saving preferences in |its own resource fork] |[...] |It's really a neat thing Wrong. It's incredibly antisocial: 1. If your application is on a readonly server, preferences can't be saved. 2. If your application is on a writable server, you always get the preferences of the last person to use the application. 3. If you do an incremental backup, the whole application has to be copied, instead of the three bits of configuration info that have changed. 4. What happens if two people on different Macs quit the application (thus trying to write to the resource fork of the application on the server) at the same time? Don't modify your application! -- Brian L. Matthews blm@6sigma.UUCP Six Sigma CASE, Inc. +1 206 854 6578 PO Box 40316, Bellevue, WA 98004