File Code Problems

Member
Posts: 45
Joined: 2002.04
Post: #1
this time I actually have a message Grin

I am going quite insane here.. nothing I try works.. and I have not been able to find any example code for what I need.

and what I need is this:

all I want is to be able to create an FSSpec to a file called "World Map" which is located in a folder called "Files" inside my programs directory..

how do I open it... I really need help on this one... I cannot progress with my engine until I get this working. I need to use to world map data to test out my code.

can someone post some code that opens a file within a folder inside the programs directory. or at least direct me to some place where I can learn how to do this..

this would be under carbon.

and I need to access the data fork of the file.

I just need to be able to create an FSSpec to the file..

then I can use FSRead etc..

I am starting to pull hair out over this... for the sake of my hair.. I need help.

thanks in advance.

Hank

/* Drunk...... fix later.... */
Quote this message in a reply
Tobi
Unregistered
 
Post: #2
Try this code. It works perfectly for me. If it doesn't work for you, please tell me.

Code:
int main(void)
{
CFBundleRef bundle;
CFURLRef bundle_url;
CFStringRef    sr;
int        i;
char routePath[1024];
char worldmapPath[1024];
FSSpec    f;
FSRef    fsr;
short ref;

//Get the application directory as a POSIX path and store it in routePath
    bundle = CFBundleGetMainBundle();
    if ( ! bundle )
        return 0;
    bundle_url=CFBundleCopyBundleURL( bundle );
    if ( ! bundle_url )
        return 0;
    sr=CFURLCopyFileSystemPath(bundle_url, kCFURLPOSIXPathStyle);
    if ( ! sr )
        return 0;
    if (!CFStringGetCString(sr, routePath, 1024, kCFStringEncodingASCII) )
        return 0;

    CFRelease( bundle_url );
    CFRelease( sr );

#ifdef __APPLE_CC__
//When you are using ProjectBuilder routePath also contains the application title at the end. This deletes it.

for (i=strlen(routePath)-1; i>0; i--)
{
if (routePath[i]=='/'){routePath[i]='\0';break;}
routePath[i]='\0';
}
#endif
strcat(routePath, "/");

//Build the path of the world map file
sprintf(worldmapPath, "%sFiles/World Map", routePath);

FSPathMakeRef(worldmapPath, &fsr, NULL);//Convert to FSSpec
FSGetCatalogInfo (&fsr, NULL, NULL, NULL, &f, NULL);//Convert to FSRef
FSpOpenDF(&f, fsRdWrPerm, &ref);//Open data fork

return 0;
}

Good luck!

-Tobi
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #3
Quote: if (!CFStringGetCString(sr, routePath, 1024, kCFStringEncodingASCII) )

Note that in this code, the routePath is defined to be 1024 characters.

In the original example I posted, I simply used 1024 because I knew it to be sufficently long for my purposes.

However, you should make sure that it is sufficiently long for your purposes, and really you probably ought to define it as the maximum path length. I'm sure that's defined in a header somewhere, but I haven't taken the time to look and see what it is.

Wade
Quote this message in a reply
WFleming
Unregistered
 
Post: #4
I'm trying to do the same thing with Classic OS (I know, I know I should be doing carbon, but I won't be able to afford a computer i'd be happy running OS X for awhile (need to get the $$ for next year's tuition first)).

After spending the last few hours digging around Inside Macintosh i've come to the conclusion that Apple has purposefully made this very hard to do without using StandardGetFile(). But the thought of making a user have to select the data files the app uses using StandardGetFile() makes me cringe.

I also found Tech Note 2015 - Locating Application Support Files under Mac OS X, but that isn't much use to me. Couldn't find anything similiar for Classic (did I miss something?

I've thought up a couple of ways that might work, but have run into problems with both.

1) I could do this:

SInt16 resRefNum

resRefNum = OpenResFile("\pMy Graphics File");

Definately easy, but OpenResFile isn't supported in Carbon (which I would like to at some point port my code to). So I need to use FSpOpenResFile(), but I need a FSSpec with it, but I don't know how to do that without StandardGetFile().

2) I could get a resRefNum for my app by

resRefNum = CurResFile();

at startup. Then find some way of getting a FSSpec using the resRefNum. Getting the FSSpec of the app file would give me the vRefNum (volume reference number) and the parID (parent directory ID) of the app and the data file (assuming they are in the same directory)?. So all I would need would be the name of the data file and I could create a FSSpec using FSMakeFSSpec().
However, I have been so far unable to find any functions that can get me a FSSpec from a resRefNum (I suspect that there is no way to actually do this).


Does anyone have any suggestions or code that might be useful?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
If you're running OS 8.6 or later you can do Carbon development. That gives you access to all the tasty bundle goodness people are using here. 8.1 gives you access to some of Carbon, but I'm not quite sure how much; whether CoreFoundation is included. My recollection is yes, but I could be wrong.

ANSI C's fopen call will get you access to the data fork of a file with a relative path if that's all you want. You'll still have to do bundle stuff when you port, but it'd be a solution for the moment.

There was a "standard" way of doing this sort of thing which involved passing a relative path and 0 volume & other flags to FSMakeSpec or something -- but I never did it myself. Somebody else?
Quote this message in a reply
WFleming
Unregistered
 
Post: #6
Quote:Originally posted by OneSadCookie
If you're running OS 8.6 or later you can do Carbon development. That gives you access to all the tasty bundle goodness people are using here. 8.1 gives you access to some of Carbon, but I'm not quite sure how much; whether CoreFoundation is included. My recollection is yes, but I could be wrong.

ANSI C's fopen call will get you access to the data fork of a file with a relative path if that's all you want. You'll still have to do bundle stuff when you port, but it'd be a solution for the moment.

There was a "standard" way of doing this sort of thing which involved passing a relative path and 0 volume & other flags to FSMakeSpec or something -- but I never did it myself. Somebody else?

I've thought about doing it carbon, but from what i've heard, often when a app in OS 8 or 9 works with CarbonLib, it doesn't mean it will work properly in OS X. Maybe someone can clarify this for me (the thought of making someone with OS X have to boot in OS 9 and then use CarbonLib to run the game seems rather unappealing)


Since I don't have access to a machine running X till at the earliest the end of summer i'm thinking i'll just stick with Classic for the time being. Plus once I get OS X (and finish this game, if it ever gets done) i'm going to try to delve into cocoa and see how that goes.

Regardless, I am going to buy a carbon book in the next few days at least, just need to figure which one I want. At least that will get me reasonably up to date with some things. But in the meantime if anyone does know a solution to my problem it would be much appreciated.
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #7
Quote:Originally posted by WFleming
I've thought about doing it carbon, but from what i've heard, often when a app in OS 8 or 9 works with CarbonLib, it doesn't mean it will work properly in OS X. Maybe someone can clarify this for me (the thought of making someone with OS X have to boot in OS 9 and then use CarbonLib to run the game seems rather unappealing)

All they meant was that certain requirements have to be met in both OSs. As long as you make sure to meet all the requirements of both OSs, then it should run in both OSs. This does not necesarrily mean that, in OS X, it would boot in OS 9. Sometimes, it means that it simply won't work. If it DOES make it boot into OS 9, it means that you have a resource set wrong (I forgot what it was called). You can find the requirements for Carbon programming in the preface of the Carbon programming book that is downloadable at mactech.com.
Quote this message in a reply
WFleming
Unregistered
 
Post: #8
Quote:Originally posted by geezusfreeek


All they meant was that certain requirements have to be met in both OSs. As long as you make sure to meet all the requirements of both OSs, then it should run in both OSs. This does not necesarrily mean that, in OS X, it would boot in OS 9. Sometimes, it means that it simply won't work. If it DOES make it boot into OS 9, it means that you have a resource set wrong (I forgot what it was called). You can find the requirements for Carbon programming in the preface of the Carbon programming book that is downloadable at mactech.com.

Sorry, should have been clearer. My understanding is that just because a game runs under CarbonLib in OS 8/9 doesn't mean it will work properly in OS X.
So if it didn't work (this is becoming very hypothetical) in X but did in 9, my understanding is that the user would have to reboot the computer in OS 9 for it to work.

My original plan was to do a classic version of the game, then release a carbon version once I can afford OS X. But I'm beginning to think that I might just not release the classic version, and wait till I get X (sometime in the next 6-12 months)
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #9
Ok. If you're gonna wait to get OS X, you might as well wait until they release Jaguar. It'll be a lot better than the current version, mainly because it'll incorporate OpenGL into all graphics, using hardware acceleration whenever it's useable. I think it's out in July sometime. I may be mistaken. Not too far off from now. I made the mistake of buying it now instead of then. Now I'll either have to get an update or be stuck without it. Stinks.
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #10
Quote:My understanding is that just because a game runs under CarbonLib in OS 8/9 doesn't mean it will work properly in OS X.

That's only partially correct. Ninety-nine percent of the Carbon code for a game is completely usable in both environments. The one part that isn't is input devices. However, there's now an input-sprocket compatibility library for OS X, so you can even keep using ISp code on OS X.

However, I would recommend you learn the OS X way of doing things too, rather than use that.

So in short, write your game in Carbon, but just call the OS X input code if the game is currently running on OS X, or the OS 9 input code if the game is currently running on OS 9.

Quote:I think it's out in July sometime. I may be mistaken.

You're definitely mistaken. Jaguar is not likely to appear until September.

Quote:I made the mistake of buying it now instead of then. Now I'll either have to get an update or be stuck without it. Stinks.

Why does it stink? You're getting use out of it now, aren't you? If you waited until September, you wouldn't have to pay for an upgrade, but you also wouldn't have been able to use it.

Wade
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #11
WFleming, are you just trying to open a resource file in Classic? If that is all, I have some simple code that does that...
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #12
Quote:Originally posted by wadesworld
Why does it stink? You're getting use out of it now, aren't you? If you waited until September, you wouldn't have to pay for an upgrade, but you also wouldn't have been able to use it.

Well, yes, but I do not have a steady income, due to the fact that I'm just a high school student with no job. Money is much more valuable to me than to somebody with a real job. I dunno. I was more frustrated when I thought it came out next month. It is worth it since it comes out in September though.
Quote this message in a reply
WFleming
Unregistered
 
Post: #13
Quote:Originally posted by jabber
WFleming, are you just trying to open a resource file in Classic? If that is all, I have some simple code that does that...

Don't worry about it. I've decided to just use OpenResFile() for the time being, and when I finally stop procrastinating and get around to doing this in carbon, i'll either use the code above or figure another way to do it.

thanks anyway
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #14
I'll give it to you anway... :) Basic idea is this:
Code:
FSSpec theSpec;
short theRes;
FSMakeFSSpec(0, 0, "\p:Data:Graphics.rsrc", &theSpec);
theRes = FSpOpenResFile(&theSpec,  fsRdWrPerm);
UseResFile(theRes);
Viola! All your resource calls will then search Graphics.rsrc. I am not sure if all (or any!) of these calls are Carbonized...
Quote this message in a reply
WFleming
Unregistered
 
Post: #15
Quote:Originally posted by jabber
I'll give it to you anway... Smile Basic idea is this:
Code:
FSSpec theSpec;
short theRes;
FSMakeFSSpec(0, 0, "\p:Data:Graphics.rsrc", &theSpec);
theRes = FSpOpenResFile(&theSpec,  fsRdWrPerm);
UseResFile(theRes);
Viola! All your resource calls will then search Graphics.rsrc. I am not sure if all (or any!) of these calls are Carbonized...

thanks,

In addition I found some code (Technical Q&A FL14) at developer.apple.com that shows how to use the Process Manager to get the vRefNum and dirID of the application. I assume it would be better to plug these into FSpOpenResFile than using 0 for them?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Recursively Packing Source Code Into One File? daveh84 15 7,045 Feb 3, 2010 08:36 PM
Last Post: AndyKorth
  Carbon File Code Muffinking 5 4,778 Jun 3, 2002 12:23 AM
Last Post: henryj