sonenbli@oxy.edu (Andrew D. Sonenblick) (10/26/89)
Ok, this is a quick one but it is very important: is there any way for an INIT to get the name of the file it is in? I need to later open the resource fork of the file and I want the user to be able to change the name of the file; hence, my INIT needs to be able to read in the file name. Please inform me or the whole net of any solution. Thanks. Ando Sonenblick: sonenbli@oxy.edu
beard@ux1.lbl.gov (Patrick C Beard) (10/26/89)
In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > > Ok, this is a quick one but it is very important: is there any way >for an INIT to get the name of the file it is in? I need to later open >the resource fork of the file and I want the user to be able to change the >name of the file; hence, my INIT needs to be able to read in the file name. >Please inform me or the whole net of any solution. Thanks. > >Ando Sonenblick: sonenbli@oxy.edu The best way is to give your init file a unique creator type. MacDTS registers these so that developers won't have conflicts. Then, since you know that the type of your file is 'INIT', just search through the system folder (every time you need your file) searching for your file with creator = '!&*(' and type = 'INIT' ('!&*(' not to be taken literally of course, unless your mad). How does one search the system folder? Ah... I'll leave that as an exercise for the reader. :^). help, help, this article needs more length! ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------
mm5l+@andrew.cmu.edu (Matthew Mashyna) (10/26/89)
Ando Sonenblick: sonenbli@oxy.edu writes: >...is there any way >for an INIT to get the name of the file it is in? I need to later open >the resource fork of the file and I want the user to be able to change the >name of the file; hence, my INIT needs to be able to read in the file name. Check the latest issue of MacTutor: Writing INITs in Think C, by J. Peter Hoddie. findMyName(name) Str255 name; { FCBPRec p; p.ioCompletion = 0; p.ioRefNum = CurResFile(); p.ioVRefNum = 0; p.ioNamePtr = (StringPtr) name; PBGetFCBInfo(&p,false); BlockMove( p.ioNamePtr,&name, 1 + *(char *)(p.ioNamePtr) ); } Matt Mashyna Macintosh Initiative, H&SS Dean's Office Carnegie Mellon
mnkonar@smallberries.SRC.Honeywell.COM (Murat N. Konar) (10/26/89)
In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > Ok, this is a quick one but it is very important: is there any way >for an INIT to get the name of the file it is in? I need to later open >the resource fork of the file and I want the user to be able to change the >name of the file; hence, my INIT needs to be able to read in the file name. A recent TechNote posted over in comp.binaries.mac tells how to do this. What happens if the user changes the name of the file AFTER the INIT runs? ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
mahboud@excelan.COM (Mahboud Zabetian) (10/27/89)
In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > Ok, this is a quick one but it is very important: is there any way >for an INIT to get the name of the file it is in? I need to later open >the resource fork of the file and I want the user to be able to change the >name of the file; hence, my INIT needs to be able to read in the file name. >Please inform me or the whole net of any solution. Thanks. > >Ando Sonenblick: sonenbli@oxy.edu You might want to try looking for the file by type and creator, and not by filename. Users will almost never change those. Then you won't have to worry about carrying around a filename string. -mahboud
zben@umd5.umd.edu (Ben Cranston) (10/27/89)
In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > Ok, this is a quick one but it is very important: is there any way > for an INIT to get the name of the file it is in? I need to later open > the resource fork of the file and I want the user to be able to change the > name of the file; hence, my INIT needs to be able to read in the file name. In article <4020@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: > The best way is to give your init file a unique creator type. MacDTS > registers these so that developers won't have conflicts. Then, since > you know that the type of your file is 'INIT', just search through > the system folder (every time you need your file) searching for your > file with creator = '!&*(' and type = 'INIT' ... I'd worry about INIT expanders running inits from other folders than the system folder. Maybe the best thing would be to save the folder number and file name and reopen it later... -- Sig DS.L ('ZBen') ; Ben Cranston <zben@Trantor.UMD.EDU> * Computer Science Center Network Infrastructures Group * University of Maryland at College Park
han@apple.COM (Byron Han, Project Scapegoat) (10/28/89)
In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > Ok, this is a quick one but it is very important: is there any way > for an INIT to get the name of the file it is in? I need to later open > the resource fork of the file and I want the user to be able to change the > name of the file; hence, my INIT needs to be able to read in the file name. Ok. Here is how to do itI 1. Do a RecoverHandle on your entry point to get the INIT handle 2. Do a HomeResFile to get the resource file refnum of the INIT file 3. You can convert the resource file refnum (which is just a file refnum) into a filename/working directory refnum pair via a call to PBGetFCPInfo 4. The wdRefNum can be converted into a vRefNum/dirID pair via a call to PBGetWDInfo But why do you want the name of your INIT file? You should NOT hard code - the user may wish to rename their INIT files and indeed may do so. +-------------------------------------------------------------------------- ---+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------- ---+ Byron Han, CommToolbox Scapegoat "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM --------------------------------------------------------------------------- ---
tim@hoptoad.uucp (Tim Maroney) (10/28/89)
One: This is largely a philosophical/aesthetic quibble, but really,
you shouldn't write into code files if you can help it. It's better to
use an external preferences file. Not only does this preserve a
valuable dichotomy between code and data, but it allows the user to
independently throw away the user/run-time settings or the code,
instead of having to discard or regenerate both at once.
Two: If you want to allow renaming without file ids, the best way to
do it is generally to use the creator longword. You can almost
trivially write code to loop over all files in the system folder until
it encounters one with your unique creator longword and the appropriate
file type, then use that. This completely bypasses the file name, and
works both under System 7.0 and earlier systems. In practice, it's
also fast enough unless you're doing very frequent updates. I don't
think you'd want to use this if you were writing the file 60 times a
second; then again, you don't want to do an OpenResFile, WriteResource,
CloseResFile every 60th of a second either!
Three: I have always felt that the ability to rename INITs is
overrated. I mean, who cares if you can or not? However, few people
agree with me on this.
--
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
"`Truth' never set anyone free. It is only *doubt* which will bring
mental emancipation."
-- Anton LaVey, quoted by Arthur Lyons, SATAN WANTS YOUchaffee@reed.UUCP (Alex Chaffee) (10/29/89)
In article <8831@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Three: I have always felt that the ability to rename INITs is >overrated. I mean, who cares if you can or not? However, few people >agree with me on this. That's because few people have never had an INIT conflict that could only be resolved by (guess what) renaming the INIT files. Renaming INITs is vital. -- Alex Chaffee chaffee@reed.UUCP ____________________
tim@hoptoad.uucp (Tim Maroney) (10/30/89)
In article <8831@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Three: I have always felt that the ability to rename INITs is >overrated. I mean, who cares if you can or not? However, few people >agree with me on this. In article <13474@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >That's because few people have never had an INIT conflict that could only be >resolved by (guess what) renaming the INIT files. Renaming INITs is vital. Any INIT so brain-damaged that this happens, or any combination of INITs which interact unpredictably in this way, should be dragged to the trash can. I don't understand how people can be so devil-may-care about their system reliability. I use very few INITs and for that reason, when my development software does something strange, I generally feel confident that it's my code's fault and I don't waste time messing around with possible INIT problems. INITs are a necessary evil and should be treated as such. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "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"
svc@well.UUCP (Leonard Rosenthol) (10/31/89)
In article <4020@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >In article <56505@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: >> >> Ok, this is a quick one but it is very important: is there any way >>for an INIT to get the name of the file it is in? I need to later open >>the resource fork of the file and I want the user to be able to change the >>name of the file; hence, my INIT needs to be able to read in the file name. >>Please inform me or the whole net of any solution. Thanks. >> > I don't know what all this mess is about searching the System Folder, etc. as that is a REAL PAIN, and it also doesn't provide help for when you use some INIT Manager that supports subFolders...So here is the piece of code that I use for getting not only my INIT's name, but also the vRefNum (OK, WDRefNum) where I am. void GetInitInfo(myName, myVRefNum) Str255 *myName; int *myVRefNum; { FCBPBRec p; int dummy; p.ioCompletion = 0; p.ioRefNum = CurResFile(); p.ioFCBIndx = 0; p.ioVRefNum = 0; p.ioNamePtr = (StringPtr)myName; dummy = PBGetFCBInfo(&p, FALSE); BlockMove(p.ioNamePtr, &myName, (long)p.ioNamePtr[0]); dummy = GetVol(NIL, myVRefNum); } [Pascal conversion is left as an exercise for the reader if required!] -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
CXT105@PSUVM.BITNET (Christopher Tate) (10/31/89)
In article <13474@reed.UUCP>, chaffee@reed.UUCP (Alex Chaffee) says: >That's because few people have never had an INIT conflict that could only be >resolved by (guess what) renaming the INIT files. Renaming INITs is vital. Seconded. A good example is hierDA (sometimes seen as "DA menuz"), which absolutely MUST be INIT'd before either Suitcase or Font/DA Juggler. The usual workaround is to add a space before the name, giving you " hierDA". In this case, renaming is certainly necessary. Also, a lot of people like to change the names of GateKeeper and Vaccine so that they are the first INIT's launched on startup. Better safe than sorry.... ------- Christopher Tate | (i do not know what is it about you cxt105@psuvm.psu.edu | that closes and opens; only something ..!psuvax1!psuvm.bitnet!cxt105 | in me understands the voice of your cxt105@psuvm.bitnet | eyes is deeper than all roses)
isle@eleazar.dartmouth.edu (Ken Hancock) (10/31/89)
In article <89303.152726CXT105@PSUVM.BITNET> CXT105@PSUVM.BITNET (Christopher Tate) writes: >In article <13474@reed.UUCP>, chaffee@reed.UUCP (Alex Chaffee) says: >Seconded. A good example is hierDA (sometimes seen as "DA menuz"), which >absolutely MUST be INIT'd before either Suitcase or Font/DA Juggler. The >usual workaround is to add a space before the name, giving you " hierDA". Um, I've always had hierDA load -last-. After Suitcase. With earlier version I had problems with hierDA if it loaded before Suitcase because it wouldn't compile the hierarchical menus of DAs loaded with Suitcase correctly. Ken -- Ken Hancock '90 | E-mail: (BITNET/UUCP/INTERNET) Computer Resource Center Consultant | isle@eleazar.dartmouth.edu ...................................................................... DISCLAIMER? I don't get paid enough to worry about disclaimers.
tim@hoptoad.uucp (Tim Maroney) (10/31/89)
In article <14362@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: > I don't know what all this mess is about searching the System Folder, >etc. as that is a REAL PAIN, What? How? I've done it in several pieces of code. The File Manager makes it tremendously easy, by using indexed files with PBGetFInfo. It's a very straightforward loop! >So here is the piece of code that >I use for getting not only my INIT's name, but also the vRefNum (OK, WDRefNum) >where I am. But like about three-quarters of the people who answered this question, you ignored his explicitly stated requirement that he wants the user to be able to rename the file. That means that he can't just save the file name at INIT run time, because it could change -- and later, he can't use CurrResFile to find out its file descriptor! PBGetFCBInfo is completely irrelevant to this problem. Kind of sloppy from someone whose first disagreement with me here was posting a mega-flame on how absolutely necessary it is to allow INIT files to be renamed, Leonard. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Next prefers its X and T capitalized. We'd prefer our name in lights in Vegas." -- Louis Trager, San Francisco Examiner
d88-jwa@nada.kth.se (Jon Watte) (10/31/89)
In article <89303.152726CXT105@PSUVM.BITNET> CXT105@PSUVM.BITNET (Christopher Tate) writes: >>That's because few people have never had an INIT conflict that could only be >>resolved by (guess what) renaming the INIT files. Renaming INITs is vital. >Seconded. A good example is hierDA (sometimes seen as "DA menuz"), which >absolutely MUST be INIT'd before either Suitcase or Font/DA Juggler. The >usual workaround is to add a space before the name, giving you " hierDA". No, this is not a good example. Although extensively tested, I have used hiedDA loaded after Suitcase. My guess is that hierDA patches AddResMenu, and that's not done until after all INITs have loaded... (It wasn't on my system, so I can't check it now. It worked then) Also, there's only ONE type of INIT that SHOULD have to be loaded in special order , namely INITs that modify the behaviour of other INITs. IconWrap, ForceMount and INIT cdev are examples of these. Any other INIT should not depend on load-order, unless it's from Microsoft :-) Happy Hacking ! h+@nada.kth.se == h+@proxxi.se -- This .signature is longer than 4 lines. If you'd like to see it in whole, please send a note to me. I'm h+@nada.kth.se and also h+@proxxi.se 8')
svc@well.UUCP (Leonard Rosenthol) (11/01/89)
In article <8851@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <14362@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: >> I don't know what all this mess is about searching the System Folder, >>etc. as that is a REAL PAIN, > >What? How? I've done it in several pieces of code. The File Manager >makes it tremendously easy, by using indexed files with PBGetFInfo. >It's a very straightforward loop! > I probably should have rephrased that statement. I did not meant that coding a search of the System Folder is difficult, it is certainly not. However many people out there (myself included) have LOTS of files in the System Folder (many of which are prefs, unused INITS, etc.) and it takes TIME to do the search each and every time the user invokes your INIT. >>So here is the piece of code that >>I use for getting not only my INIT's name, but also the vRefNum (OK, WDRefNum) >>where I am. > >But like about three-quarters of the people who answered this question, >you ignored his explicitly stated requirement that he wants the user to >be able to rename the file. That means that he can't just save the >file name at INIT run time, because it could change -- and later, he >can't use CurrResFile to find out its file descriptor! PBGetFCBInfo >is completely irrelevant to this problem. > It is true that this does not provide for renaming on the fly, but it does provide for non-hardcoding names so that it could be renamed before use or by turning it off, renaming and turning it back on - not the greatest BUT much better than hardcoding!! It appears to me that a combination of our two methods would be the best bet. First the INIT checks for the values it stored at startup with the PBGetFCBInfo and GetVol calls - if the file with that info does not exist then it can perform a search to find it based on the creator - HOWEVER the search could possibly be two-fold. The search should start in the vRefNum returned by GetVol, and if that value is NOT the same as mySysEnvRec.sysVRefNum then the System Folder should also be searched in case the user moved it. How's that for an all purpose, and cover most/all cases solution?!??!? -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
tim@hoptoad.uucp (Tim Maroney) (11/02/89)
In article <14362@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: > I don't know what all this mess is about searching the System Folder, >etc. as that is a REAL PAIN, In article <8851@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >The File Manager >makes it tremendously easy, by using indexed files with PBGetFInfo. In article <14385@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: >I did not meant that >coding a search of the System Folder is difficult, it is certainly not. However >many people out there (myself included) have LOTS of files in the System Folder >(many of which are prefs, unused INITS, etc.) and it takes TIME to do the >search each and every time the user invokes your INIT. Well, we still don't know how often the INIT is getting called, so it's hard to say how significant this will be. I think it should be noted that due to the efficiency of the B*-tree structures employed, directory operations on the Mac are generally very fast. I think it's silly to have more than 100 files in your system folder, and I doubt that scanning through that many would take a humanly noticeable time. But this is something the implementor of the INIT can easily test. > It is true that this does not provide for renaming on the fly, but it >does provide for non-hardcoding names so that it could be renamed before use >or by turning it off, renaming and turning it back on - not the greatest BUT >much better than hardcoding!! Not if you put yourself in the place of the user. Let's say you rename the file, and the INIT suddenly stops functioning. What is the natural conclusion, the one conclusion that most users are likely to come to? Right -- that you aren't allowed to rename the INIT. So they change it back. > It appears to me that a combination of our two methods would be the best >bet. First the INIT checks for the values it stored at startup with the >PBGetFCBInfo and GetVol calls - if the file with that info does not exist then >it can perform a search to find it based on the creator - HOWEVER the search >could possibly be two-fold. The search should start in the vRefNum returned by >GetVol, and if that value is NOT the same as mySysEnvRec.sysVRefNum then the >System Folder should also be searched in case the user moved it. > How's that for an all purpose, and cover most/all cases solution?!??!? Sounds good to me! Shouldn't be too much code, either. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "He goes on about the wailing and gnashing of teeth. It comes in one verse after another, and it is quite manifest to the reader that there is a certain pleasure in contemplating the wailing and gnashing of teeth, or else it would not occur so often." -- Bertrand Russell, "Why I Am Not a Christian"
chaffee@reed.UUCP (Alex Chaffee) (11/02/89)
>In article <13474@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >That's because few people have never had an INIT conflict that could only be >resolved by (guess what) renaming the INIT files. Renaming INITs is vital. In article <8838@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Any INIT so brain-damaged that this happens, or any combination of >INITs which interact unpredictably in this way, should be dragged to >the trash can. I don't understand how people can be so devil-may-care >about their system reliability. I use very few INITs and for that >reason, when my development software does something strange, I >generally feel confident that it's my code's fault and I don't waste >time messing around with possible INIT problems. INITs are a necessary >evil and should be treated as such. When I'm programming, and get a system crash I don't understand, the first thing I do is turn off all my INITs and reboot. (I can actually turn them off while rebooting, thanks to an init manager which, incidentally, I had to rename to come first in the list.) However, there are many "brain-damaged" INITs whose authors were less than compulsive about compatibility, yet whose functions I find indispensible. Until I get around to writing replacements (which I'm actually doing, as a matter of fact, for Pop-Keys), I can live with keeping "evil" INITs in my system. And really, if I can't _resolve_ a conflict by renaming, out it goes. But if the evil is exorcised by renaming, I'm happy. But if the INIT loses functionality if its name changes... even if it is otherwise a paragon of compatibility... I get mad! (Well, not _that_ mad...) "Nor is it a consequence of my bed's being covered with leaves that I am not hallucinating that it is." - Barry Stroud ____________________ -- Alex Chaffee chaffee@reed.UUCP ____________________