Re: Opening a file from a DMG.
Re: Opening a file from a DMG.
- Subject: Re: Opening a file from a DMG.
- From: Mike Fischer <email@hidden>
- Date: Tue, 31 May 2005 17:36:24 +0200
Hi Matt,
Am 31.05.2005 um 6:23 schrieb "Matt Fox-Wilson"
<email@hidden>:
Hi all,
I've been having a couple of problems opening a file from inside a .app
bundle in a dmg.
As Alex has commented, this is not an Xcode question.
My app stores a resource file (its own format, flat binary file)
inside its
.app bundle, and it needs to read from it when the app opens to
construct
custom UI elements. This works fine when I've got the app sitting on
the
desktop or in a folder somewhere on my machine, but if I try and run
the app
from the dmg folder I'm going to distribute it in, I get an error.
Experimenting with it, the path the app is identifying to its resource
file
looks correct, eg:
<dmgname>:<app.app>:Contents:MacOS:Resources:resource.grf
The Resources folder there is stored alongside the executable for cross
platform code reasons.
Anyway, calling FSOpenFork for that path is returning err -35 (nsvErr,
Volume not found).
How are you converting the old school HFS path to an FSRef? Are you
checking the errors during this conversion? I'll bet that you aren't
and that the FSRef ist invalid even before you try to use it in
FSOpenFork.
When I drag the app to my machine (say, to the root of my main HD),
the path
format comes back:
Macintosh HD:<app.app>:Contents:MacOS:Resources:resource.grf
Now that looks pretty much the same, and works fine with no errors. I
checked in the /Volumes folder to make sure that the dmg actually adds
a
volume with its name, and indeed it does.
Does anyone know why FSOpenFork is failing in the case that the volume
is a
dmg? While I don't particularly want people running the app from that
folder
anyway, it looks bad if it fails to launch from there, and I can't see
any
reason why the path would be invalid in this case.
Just a guess: The boot volume is a special case because its UNIX path
is just "/". All other volumes use "/Volumes/<volume name>/". (You
could try a different partition or an external disk or network volume
to verify this. But this is rather pointless anyway - see below.)
So my guess is that your conversion from HFS path to UNIX path to FSRef
is flawed. (Note that HFS paths are also inherently flawed because they
can't differentiate between two volumes with the same name. And they
probably don't handle long Unicode names either.)
Why are you using a HFS path at all? Why don't you use the CFBundle
routines to find your "resource" file?
Something like CFBundleCopyResourceURL() should do the trick. See
<http://developer.apple.com/documentation/CoreFoundation/Reference/
CFBundleRef/Reference/chapter_2.1_section_4.html>.
HTH
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: <http://homepage.mac.com/mike_fischer/index.html>
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden