Classic: FSSpec from filename?
John Boero
every day:
For a long time, I've seen sample code use FSSpecs for files that in all
practicality should be referred to by path and name. The only way I can
find to get an FSSpec is with StandardGetFile. Isn't there a simple way to
refer by filename? PLEASE ?
Thanks
John
matt neuburg
> For a long time, I've seen sample code use FSSpecs for files that in
> all practicality should be referred to by path and name.
"Should"? See p. 2-28 of IM-Files. m.
--
matt neuburg, phd = ma...@tidbits.com, http://www.tidbits.com/matt
REALbasic: The Definitive Guide! 2nd edition!
http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt
Subscribe to TidBITS. It's free and smart.
David Stone
> Hello everybody. I don't follow this group much, so I hope this isn't asked
> every day:
>
> For a long time, I've seen sample code use FSSpecs for files that in all
> practicality should be referred to by path and name.
Google the group archives if you really want to know why that isn't
recommended.
The only way I can
> find to get an FSSpec is with StandardGetFile. Isn't there a simple way to
> refer by filename? PLEASE ?
From MacOS 7.0, using FSMakeFSSpec() generated the required FSSpec
from the volume/parent folder/file name.
Check the Carbon docs on Apple's developer website for current details,
though - some of us are still in the stone age when it comes to programming.
John Boero
directory- just like you create ifstreams by name. I don't see how that's
possible. I have gone through IM-Files.
Thanks anyway
Per Bull Holmen
> In article <BA9B5544.14615%jlb...@uwm.edu>,
> John Boero <jlb...@uwm.edu> wrote:
>
> No. On MacOS <= 9 it is possible to mount a bunch of filesystems with
> the same name so the path is ambigous.
Also a relative path? (relative to the applications folder)
Per
Mark Day
<jlb...@uwm.edu> wrote:
> Sorry. Specifically, I want to refer to files relative to the program's
> directory- just like you create ifstreams by name. I don't see how that's
> possible. I have gone through IM-Files.
You can use FSMakeFSSpec. The third parameter is a pathname, which can
be relative to a volume/directory you specify, or relative to the
current working directory. See
<http://developer.apple.com/techpubs/macosx/Carbon/Files/FileManager/Fil
e_Manager/file_manager/function_group_15.html#//apple_ref/c/func/FSMakeF
SSpec>.
Technical Q&A FL14 <http://developer.apple.com/qa/fl/fl14.html> has
some sample code showing how to figure out the vRefNum and dirID to
pass as the first two parameters.
-Mark
David Stone
The problem is, you can never guarantee that the files will remain in the
same location relative to the applications folder, especially if the
application is on a network/shared system with multiple users. This is
partly why you have all kinds of FindFolder constants - so you can have
preferences files in the Preferences Folder, temporary items in the Temporary
Items Folder, etc, and still have a (relatively) easy way for the programmer
to find all these locations.
Use the FSMakeFSSpec() and other functions, and test for the error codes
that these routines can return. Ultimately, your users will thank you!!
David Phillip Oster
John Boero <jlb...@uwm.edu> wrote:
> Sorry. Specifically, I want to refer to files relative to the program's
> directory- just like you create ifstreams by name. I don't see how that's
> possible. I have gone through IM-Files.
Relative pathnames are quite common on Mac.
where on Unix, you'd say "../../foo", on Mac you'd say: "\p:::foo",
../../../foo -> ::::foo
../../foo -> :::foo
../foo -> ::foo
./foo -> :foo
you get the vRef and dirId from FindFolder, or from GetProcessInfo
Jøhnny Fävòrítê (it means "genetic antagonism")
> Use the FSMakeFSSpec() and other functions, and test for the error
> codes that these routines can return. Ultimately, your users will
> thank you!!
Hey, are we having the "Mac sticky FSSpec versus the rest of the world's
pathnames" debate again? Because personally I'm now even more convinced
that pathnames are the way to go. Maybe not on OS9 and below, but
definitely on OSX.
Yes, I've heard all the "but Mac users expect things to work this way"
arguments. And apparently they expect to have lots of unimaginably
stupid problems that nobody else experiences also. Like trying to get
rid of something by throwing it away and the Mac just keeps right on
using it, stalker-like. How many times have I read posts like that
around here? "I fixed my problem by emptying the trash?" Amazing.
I think FSSpecs cause WAY more problems than they solve.
Per Bull Holmen
wrote:
In the sole example of things moved to the trash I agree.... but
usually, I prefer things NOT to stop working only because I have moved
some folders on my HD. But applications shouldn't be able to use files
in the trash. However, that's just a detail in the implementation, not a
principal fault with "the mac way".
For a clear majority of personal computer users, (PC and Mac users)
"unimaginably stupid problems" means that all they did was move a
folder, and now everything stopped working!!! The common user doesn't
even know what a pathname is.
In the example in this thread, regarding people moving i.e. application
data files out of the application's folder, maybe even to another HD,
and still expect everything to work - there must be a limit to
everything hahhahhah... :)
Per
Per Bull Holmen
wrote:
> David Stone wrote:
In the sole example of things moved to the trash I agree.... but
usually, I prefer things NOT to stop working only because I have moved
some folders on my HD. But applications shouldn't be able to use files
in the trash. However, that's just a detail in the implementation, not a
principal fault with "the mac way".
For a clear majority of personal computer users, (PC and Mac users)
"unimaginably stupid problems" means that all they did was move a
folder, and now everything stopped working!!! The common user doesn't
even know what a pathname is.
In the example in this thread, regarding people moving i.e. application
data files out of the application's folder, or rearranging inside an
applications folder, and still expect everything to work - there must be
Jøhnny Fävòrítê (it means "genetic antagonism")
Per Bull Holmen wrote:
> For a clear majority of personal computer users, (PC and Mac users)
> "unimaginably stupid problems" means that all they did was move a
> folder, and now everything stopped working!!! The common user doesn't
> even know what a pathname is.
Yes, well. "The common user" has to learn all kinds of unnatural things
to use a computer. "Intuitive" most often means "what I'm used to."
I'm sure the original Mac designers meant well but I remain convinced
they solved a small problem by introducing a much bigger problem. If
you rename a file, it is now a different file, for the purposes of
location. That's kind of fundamental.
What about the times where you really *do* want to remove the connection
between a file and an app that knows about it? Say you suspect your
app's preferences file is hosed and you want to try running the app
without it, but you want to put it back if you're wrong. If you're
subject to the Mac's usual stalker-like behavior the only thing I could
think to do would be to put it on a floppy or something and then eject
it for the test.
Greg Weston
"genetic antagonism <thi...@fake.com> wrote:
Yes. Amazing how frustrated people can get when they don't take five
minutes to learn the most basic aspects of their tools. I've had to
talk people through standard dialogs (file pickers and the like) and
even relatively atomic things like scrollbars over the phone.
> I think FSSpecs cause WAY more problems than they solve.
Only for programmers that think paths are the be-all and end-all of
file specification.
Besides, FSSpecs aren't for long-term usage. They're a concise way of
passing around a file specifier during the course of a single event,
but they are no more reliable than paths across passes through the
event loop. For long-term reference, you want aliases. Both avoid the
issue of non-unique paths.
G
Greg Weston
"genetic antagonism <thi...@fake.com> wrote:
> Oh good, I trolled somebody into this tired old subject yet again.
>
> Per Bull Holmen wrote:
> > For a clear majority of personal computer users, (PC and Mac users)
> > "unimaginably stupid problems" means that all they did was move a
> > folder, and now everything stopped working!!! The common user doesn't
> > even know what a pathname is.
>
> Yes, well. "The common user" has to learn all kinds of unnatural things
> to use a computer. "Intuitive" most often means "what I'm used to."
> I'm sure the original Mac designers meant well but I remain convinced
> they solved a small problem by introducing a much bigger problem. If
> you rename a file, it is now a different file, for the purposes of
> location. That's kind of fundamental.
Aside from the fact that it's false (You can have your name legally
changed. Does that mean you're a different person?) and a bad analogy
(we're talking about moving to a different address, not assuming a new
identity), what does "kind of fundamental" mean?
> What about the times where you really *do* want to remove the connection
> between a file and an app that knows about it? Say you suspect your
> app's preferences file is hosed and you want to try running the app
> without it, but you want to put it back if you're wrong.
You move the file out of the preferences directory. If the app is
written correctly, it will not find it. If the app _does_ find it,
complain to the author about their coding error. But they probably
would have heard about it years ago when it started loading the wrong
prefs in the older Mac OS Multiple Users environment.
G
Miro Jurisic
Jøhnny Fävòrítê (it means "genetic antagonism") <thi...@fake.com> wrote:
> Yes, I've heard all the "but Mac users expect things to work this way"
> arguments. And apparently they expect to have lots of unimaginably
> stupid problems that nobody else experiences also. Like trying to get
> rid of something by throwing it away and the Mac just keeps right on
> using it, stalker-like. How many times have I read posts like that
> around here? "I fixed my problem by emptying the trash?" Amazing.
That has absolutely nothing to do with FSSpecs, so if you're gonna whine about
something you could at least do us all the favor of knowing what you are talking
about.
meeroh
John Boero
I finally got the setup code to compile and set the default directory, but
there's some glitch with FSMakeFSSpec. It takes a uselessly outdated
ConstStr255Param as the pathname, but I can't figure out a way to actually
create one that works. In Metrowerks Debugger, I notice any string I give
it fills after the null terminator with extra zeros. If I select the value
and deselect it, for some reason, it cuts off the extra terminators and
FSMakeFSSpec works. Otherwise, nothing happens. I even checked "Use
unsigned chars" in the settings.
Any ideas?
Thanks
John
Miro Jurisic
wrote:
> I finally got the setup code to compile and set the default directory, but
> there's some glitch with FSMakeFSSpec. It takes a uselessly outdated
> ConstStr255Param as the pathname, but I can't figure out a way to actually
> create one that works. In Metrowerks Debugger, I notice any string I give
> it fills after the null terminator with extra zeros. If I select the value
> and deselect it, for some reason, it cuts off the extra terminators and
> FSMakeFSSpec works. Otherwise, nothing happens. I even checked "Use
> unsigned chars" in the settings.
Str255 and its relatives do not use NUL-teminated strings. They use Pascal
strings. You need to call CopyCStringToPascal on your filename to convert it.
hth
meeroh
Frederick Cheung
> AAAAAAAAAaaa!!! I'm ready to kick Codewarrior in the face!
>
> I finally got the setup code to compile and set the default directory, but
> there's some glitch with FSMakeFSSpec. It takes a uselessly outdated
> ConstStr255Param as the pathname, but I can't figure out a way to actually
> create one that works. In Metrowerks Debugger, I notice any string I give
you can create a constant one like so:
Str255 name="\pMy file name";
A str255 is just an array of 256 unsigned characters, the first one is the
length of the string.
(Str63 and Str31 are defined similarly)
There are functions such as PLstrcpy, PLstrcat which perform the same
tasks as their C string equivalents.
And by the way, you shouldn't use the name field of an FSSpec in a call to
FSMakeFSSpec, ie don't do
FSSpec f;
PLstrcpy(f.name,"\pmy file");
err=FSMakeFSSpec(myVolnum,myDirID,f.name,&f);
Fred
Jøhnny Fävòrítê (it means "genetic antagonism")
and use FSPathMakeRef() instead, which takes a C string instead of a
Pascal string. Then you're not limited to 255-chars-or-less paths.