 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / January 2005Open and read resource forks for dummies (i.e.: Windows programmer)
This might be the Age of Aquarius and all, but I must deal with resource forks on MacOS 9 and 10 in a plugin using CodeWarrior Pro 9 (with a Classic target). This is C++, fyi. My MacOS programming is, well, (looks at calendar) about 10 days old. My C++ programming experience is several years; my overall programming experience is nearing 20 years. First it was 'no exceptions in SDK plugin' (that worked perfectly well on Windows). I worked around that. But I have no idea on how to open and read resource forks on MacOS. I can actually do it in Windows because I have a REAL file to access. I mean, do I use Carbon, Cocoa, Darwin, BSD, ANSI C, or what here? Which API, which headers, which methods, what approach? The information is virtually nonexistent (he says after about six hours of intensive Googling and developer.apple.com and comp.sys.mac.programmer searching). Robert > This might be the Age of Aquarius and all, but I must deal with > resource forks on MacOS 9 and 10 in a plugin using CodeWarrior Pro 9 [quoted text clipped - 16 lines] > > Robert If you're looking to read the resource fork actually _as_ a set of resources, rather than as a stream of bytes, you're looking for a chunk of the API called the Resource Manager. If you are looking at it as a stream, check FSpOpenRF or FSOpenFork.  SignatureChange account to gw when responding by mail. I'm looking to open the resource fork of a resource path, the fork having a thumbnail image in PICT format within it. So, the guess is as a set of resources. But which? When I do a search for "Resource Manager" at developer.apple.com, it returns 2610 documents, many are Carbon related, others are driver related, others MacOSX/bundle related, and applescript, and so on. This is a Classic target (CFM lib) which must work both in 9.x and 10.x (since the plugin's host application supports both and the plugin SDK requires this support - No MacOSX support). Thanks, Robert dans l'article 1106245353.624420.78860@c13g2000cwb.googlegroups.com, kuroyume à templer@vplayground.com a écrit le 20/01/05 19:22 : > I'm looking to open the resource fork of a resource path, the fork > having a thumbnail image in PICT format within it. So, the guess is as [quoted text clipped - 11 lines] > Thanks, > Robert The complete reference is there: http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/i ndex.html Eric Will the Carbon API work in a native OS9 environment? Thank you, Robert dans l'article 1106249653.365751.160030@f14g2000cwb.googlegroups.com, kuroyume à templer@vplayground.com a écrit le 20/01/05 20:34 : > Will the Carbon API work in a native OS9 environment? > > Thank you, > Robert Yes. That's what it was designed for in the first place: work in both Mac0S 9 and MacOS X. Eric > dans l'article 1106249653.365751.160030@f14g2000cwb.googlegroups.com, > kuroyume à templer@vplayground.com a écrit le 20/01/05 20:34 : [quoted text clipped - 3 lines] > Yes. That's what it was designed for in the first place: work in both Mac0S > 9 and MacOS X. You are wrong. Carbon was not designed to work on Mac OS 9 and Mac OS X. It was designed to provide a transition path from Mac OS 9 to Mac OS X. There are numerous parts of Carbon that are only available on Mac OS X. Specifically, if you look in File Manage headers, you can find at least one function in each of the following categories: 1. Function available in CarbonLib on Mac OS 9 and in CarbonLib on Mac OS X 2. Function available in CarbonLib on Mac OS X but not in CarbonLib on Mac OS 9 3. Function available in Carbon.framework but not in CarbonLib (on 9 or X) In the Resource Manager, there is at least one function that is available in Carbon.framework but not in CarbonLib (on 9 or X). meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> Okay, if Carbon is not totally suitable, should I still use it while taking care in which functions I use? Or, is there a more fundamental interface API that is compliant with OS9 and OSX? And I agree with Miro about the design of Carbon, which is why I asked. My main problem is that I only have a Classic interface under Panther and no true stand-alone OS9 for testing - leaving that up to brave Mac users testing the demo version. Thanks, Robert P.S.: How are you quoting? My usenet access is limited to, eh, free using Google Groups. :) > Okay, if Carbon is not totally suitable, should I still use it while > taking care in which functions I use? Or, is there a more fundamental > interface API that is compliant with OS9 and OSX? If you are compiling a Mac OS 9 application and you want it to also work on Mac OS X, the best place to start is by creating a PPC Carbon project in CW. That will set you up with headers that cover the subset of Carbon supported by Mac OS 9. A very small number of esoteric functions is not supported by Mac OS X, but you will probably not run into them, so don't worry about it. If you later come to a point where you want to take advantage of APIs that are only available on Mac OS X, you can easily adjust your project, but there is no point with adding that complexity at this time. > P.S.: How are you quoting? My usenet access is limited to, eh, free > using Google Groups. :) MT-NewsWatcher. meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> Your ISPs spam filters are out of control! My message to you, below, was bounced with the error: 66.80.201.152 failed after I sent the message. Remote host said: 500 Mail appears to be unsolicited -- send error reports to postmaster@yourdomain.com One more thing, since you're so new to the Mac you may not have figured out your way around the docs: Go to developer.apple.com, click the link to documentation, then click the link to Carbon. This will get you to a page that lists categories of Carbon documents--for instance the link to files will get you a list that includes the resource manager. Basically the carbon docs page should be your starting point for researching the APIs you need. > Your ISPs spam filters are out of control! My message to you, below, was > bounced with the error: > > 66.80.201.152 failed after I sent the message. > Remote host said: 500 Mail appears to be unsolicited -- send error reports > to postmaster@yourdomain.com Yes, they are. I've been at my sysadmin for weeks now trying to get him to either dump the horrid thing or fix it. Believe me, I don't like it either - it's having an impact on my business. > One more thing, since you're so new to the Mac you may not have figured out > your way around the docs: [quoted text clipped - 4 lines] > the resource manager. Basically the carbon docs page should be your starting > point for researching the APIs you need. It's not quite as simple as finding one's way around the docs (of which there are tens of thousands), but knowing what to look for and use. If this were a MacOSX Application - no problem - there are enough examples to kill a PC. But it ain't. It's a C++ SDK plugin PPC Shared lib - whatever they specify for compliance, I must follow. For libraries, it has MSL_C_Carbon, MSL_C++_PPC, CarbonLib, MSL_Runtime_PPC. That gives me at least four choices from which to start. I checked out the C++ PPC first - nothing of interest. But I wasn't quite so sure of Carbon (which is why I asked here) and which of the fifty Open methods to use. There isn't a single Sample Code which describes a simple way to do what I need. There is no need for file locking, writing, copying, changing or anything. Just open the resource fork, get the PICT data, and close the resource fork. So simple sounding, that they forgot to show any code for doing it. ;) Seems that developer.apple.com is assuming that developers have been there for over ten years and this is old hat or that new developers aren't touching anything remotely ancient, so give 'em the fancy new stuff. Where's the inbetween? Where's the "bring up to speed" stuff in this area. None of the code that I checked out was less than vast and complex. You know, on my Windows version, I opened and parsed the PICT resource file out in one short and concise function! Is this possible for a Mac resource fork? Thanks, Robert > For libraries, it has MSL_C_Carbon, MSL_C++_PPC, CarbonLib, > MSL_Runtime_PPC. The MSL libraries are just the implementation of C & C++ standard libraries and the C runtime support (initializing global static vars and all the other stuff that happens before main is entered and after it's done). > Seems that developer.apple.com is assuming that developers > have been > there for over ten years and this is old hat or that new developers > aren't touching anything remotely ancient, so give 'em the fancy new > stuff. Where's the inbetween? Where's the "bring up to speed" stuff > in this area. The best bring up to speed stuff was in the printed version of Inside Macintosh, which is no longer published. You are right that they do not make it easy to learn from scratch how to program for the OS that they no longer develop. It makes some sense, in that the vast majority of new applications don't need to support OS 9, but of course there are exceptions. I would second both the suggestion that you might want to get Bricknell's "Carbon Programming" and that you might be overthinking things: <http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/ resourcemgr/function_group_14.html#//apple_ref/doc/uid/TP30000154/F01991> Once on that page, you want to click the "Show TOC" link at the top to get the table of contents frame to make it easy to navigate the rest of the Resource Manager info. > > Seems that developer.apple.com is assuming that developers > > have been [quoted text clipped - 5 lines] > The best bring up to speed stuff was in the printed version of Inside > Macintosh, which is no longer published. I have several volumes of the newer (black spine) IM series which I'm willing to send (any or all) to anyone who wants them for the price of shipping. G SignatureChange account to gw when responding by mail. > I have several volumes of the newer (black spine) IM series which I'm > willing to send (any or all) to anyone who wants them for the price of > shipping. Me too. I have nearly all of them. I didn't offer because based on the times of the poster's message and the name on the email account, I expect that shipping costs would be prohibitive ;-) But hey, the offer is open... >There isn't a single Sample Code which describes a simple way to do >what I need. There is no need for file locking, writing, copying, >changing or anything. Just open the resource fork, get the PICT data, >and close the resource fork. So simple sounding, that they forgot to >show any code for doing it. ;) One of Apple's greatest treasures is MoreFiles. look in Metrowerks CodeWarrior 9.0/Metrowerks Codewarrior/Mac OS Support/(Third Party Support) /MoreFiles You will probably find they have a routine to do anything you want to do. There is also an X version of this in the same folder. Ron SignatureMetrowerks Community Forum is a free online resource for developers to discuss CodeWarrior topics with other users and Metrowerks' staff -- http://www.metrowerks.com/community -- Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com > One of Apple's greatest treasures is MoreFiles. > [quoted text clipped - 6 lines] > > Ron Thank you, Ron. I'll take a look at the examples in the folder and try the MW forums. Robert > For libraries, it has MSL_C_Carbon, MSL_C++_PPC, CarbonLib, > MSL_Runtime_PPC. That gives me at least four choices from which to > start. I checked out the C++ PPC first A Runtime for a programming language provides only the absolute core features to get an executable in the specific language to bootstrap and start. Standard C has no notion of "Files with Forks". Standard C++ shares most of the assumptions about platfor abstraction and has notion of "Files with Forks". So what remains in the only platform specific file, CarbonLib. > There isn't a single Sample Code which describes a simple way to do > what I need. There is no need for file locking, writing, copying, > changing or anything. Just open the resource fork, get the PICT data, > and close the resource fork. So simple sounding, that they forgot to > show any code for doing it. ;) The typical sample for that is an File Selector dialog, so you might find it in the Navigation Services sample code. If you need to do more from the Plug-In level, "A Fragment of Your Imagination" of "Joe Zobkiw" is the closest thing describing the at that time usual Plug-In-architectures consisting of CodeResources etc. OTOH, it pre-dates Carbon many years, and some rules changed since then.. Regards, Tom_E SignatureThis address is valid in its unmodified form but expires soon. > A Runtime for a programming language provides only the absolute core > features to get an executable in the specific language to bootstrap and [quoted text clipped - 3 lines] > > Standard C++ shares most of the assumptions about platfor abstraction > and has notion of "Files with Forks". > > So what remains in the only platform specific file, CarbonLib. Well, not so fast there. msl_c_CARBON has carbon in it. And being new and all that, anything foreign with 'PPC' in it qualifies as part of my search path. That includes all four libraries. ;) > The typical sample for that is an File Selector dialog, so you might > find it in the Navigation Services sample code. [sarcasm]Why didn't I think of that. Of course, samples of resource code would be in Navigation Services, not Resource Manager or File Manager![/sarcasm] **** general comments **** This is exactly why the comment about "foundation and bedrock". Okay, not quite correct. Should have been: has become so deeply integrated. And to the point that for a newbie it is an avalanche of information to sort through just for this process. Not overthinking, but definitely confused. I see that there are differences in accessing System resources and Application resources as compared to other resources. And Carbon has at least five or six methods just to open a resource (shall I list them? - though current reading points to FSpOpenResFile() as the likely candidate). I have no idea how to construct an FSSpec and get these ID numbers and so forth. I understand some of the details (that each volume and folder has a unique number), but not the process. And I agree that support of an OS no longer developed should not be mandatory, but in this case I must remind all that there is STILL a Classic interface in the latest MacOS and there are still applications that either only run in that mode (e.g.: Poser 4/PP - whose files are at the heart of my task) or only support that level in their programmer interfaces (e.g.: Cinema 4D C++ SDK). Robert > And Carbon has at least five or six > methods just to open a resource (shall I list them? - though current > reading points to FSpOpenResFile() as the likely candidate). I have no > idea how to construct an FSSpec and get these ID numbers and so forth. > I understand some of the details (that each volume and folder has a > unique number), but not the process. This is an awful place to have to start learning Carbon, because there's a ton of legacy cruft in there to support old applications. Which method you use to access a file depends mostly on what information you have at hand. FSSpec are legacy structures that from the days when file names were limited to 31 single-byte characters. FSRefs are the modern equivalent which can deal with file names of up to 255 Unicode characters. But FSRefs have a restriction that they can only point to an existing file, whereas FSSPecs could represent "the file I'm about to create" in an existing folder, which leads us all to building our own little classes and utility functions around FSRefs. There are also FSPath, intended for translating between path names and more "Mac-centric representations" and FSURL, intended for the obvious URL-like uses of representing remote data but sometimes useful as intermediate representation--especially when Carbon interfaces to a Cocoa-centric API happen to return an FSURL. FSRef is probably what you want to use. As to how to build an FSRef, you start with either the Folder Manager using the FSFindFolder function to locate a common system folder: <http://developer.apple.com/documentation/Carbon/Reference/Folder_Manager/fo lder_manager_ref/function_group_2.html#//apple_ref/doc/uid/TP30000238/F16387 Or you start with the CFBundle functions to find a location within the bundle of the currently executing application: <http://developer.apple.com/documentation/CoreFoundation/Reference/CFBundleR ef/Reference/function_group_2.html#//apple_ref/doc/uid/20001191/147985> <http://developer.apple.com/documentation/CoreFoundation/Reference/CFBundleR ef/index.html#//apple_ref/doc/uid/20001191> Or in your case you may be provided a location by the hosting application as part of your plug-in's initialization. If you're allowed to package your plug-in as a bundle, then you may be able to use the bundle functions to access your resource file directly, without any further digging through the file system. See here for information about bundle structures: <http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundle s/index.html> If you need to translate an FSURL or an FSSpec or an FSPath to an FSRef: <http://developer.apple.com/documentation/CoreFoundation/Reference/CFURLRef/ Reference/function_group_3.html#//apple_ref/doc/uid/20001206/F16227> <http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file _manager/function_group_11.html#//apple_ref/doc/uid/TP30000107/TPXREF113> <http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file _manager/function_group_8.html#//apple_ref/doc/uid/TP30000107/TPXREF110> If you need to navigate through the file system from a starting FSRef: <http://developer.apple.com/documentation/Carbon/Reference/File_Manager/inde x.html> If you need to translate an FSSRef to an FSSpec: <http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file _manager/function_group_1.html#//apple_ref/doc/uid/TP30000107/F13082> To learn more about where Apple thinks you should put your files: <http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/ind ex.html> > There are also FSPath, No there isn't. Not that I've ever heard of or can find documented right now, anyway. There are utilities to convert to and from paths, but the paths in those cases are just byte buffers containing strings that are POSIX pathnames. SignatureChange account to gw when responding by mail. > > The typical sample for that is an File Selector dialog, so you might > > find it in the Navigation Services sample code. > > [sarcasm]Why didn't I think of that. Of course, samples of resource > code would be in Navigation Services, not Resource Manager or File > Manager![/sarcasm] You were asking for code for an specific task that should already have ready to use available. Of course, you can also combine some File Manager Samples (FSSpec <-> FSRef), Resource Manager samples (CurResFile, OpenResource, ..), some preview resources technote (the necessary ResID), and of course new technotes for bundled documents. > **** general comments **** > > This is exactly why the comment about "foundation and bedrock". Okay, > not quite correct. Should have been: has become so deeply integrated. > And to the point that for a newbie it is an avalanche of information to > sort through just for this process. There used to be pretty decent documentation (New Inside Macintosh) that unfortunately is deprecated and not in print any more. Combine it with the "Carbon Porting Guide" and it gets somewhat "current" > I have no > idea how to construct an FSSpec and get these ID numbers and so forth. > I understand some of the details (that each volume and folder has a > unique number), but not the process. On places where on Windows and Unix an (full or partial) path is used one of the two MacOS ways to describe an file (FSSpec, deprecated due to its 31 chars in a single encoding name limit, or FSRef, 255 Unicode chars) is used. You USUALLY do not have to construct it, you get it from other APIs. [...] > mandatory, but in this case I must remind all that there is STILL a > Classic interface in the latest MacOS No need to remind me, I write Plug-Ins for a variety of applications that partially still run in Classic.. Regards, Tom_E SignatureThis address is valid in its unmodified form but expires soon. > You were asking for code for an specific task that should already have > ready to use available. Of course, you can also combine some File > Manager Samples (FSSpec <-> FSRef), Resource Manager samples > (CurResFile, OpenResource, ..), some preview resources technote (the > necessary ResID), and of course new technotes for bundled documents. I don't quite understand the first sentence. :) But, from whenever Resources were first introduced to MacOS until now, this should be a rather general task. In what way is opening/closing a resource fork attached to a file 'specific'? Do MacOS programmers understand the idea of Code Snippets or partial examples? Everything that I've seen is complete applications! > There used to be pretty decent documentation (New Inside Macintosh) that > unfortunately is deprecated and not in print any more. Combine it with > the "Carbon Porting Guide" and it gets somewhat "current" > > On places where on Windows and Unix an (full or partial) path is used > one of the two MacOS ways to describe an file (FSSpec, deprecated due to > its 31 chars in a single encoding name limit, or FSRef, 255 Unicode > chars) is used. You USUALLY do not have to construct it, you get it from > other APIs. FSRef, yes, I looked at that. The function FSPathMakeRef() is only good for 10.1. I haven't found an earlier alternative yet. But I DO have to construct it. The SDK that I'm using has NO OS specific functionality - regular OS-specific accesses are hidden with no support for specific OS features, like resource forks. File paths/names are store in a Filename class, retrieved as Strings. So, I have to go from String (SDK's internal String class) to UInt8* to FSSpec in order to use FSpOpenResFile(). I can get a CHAR* (standard C string) out of the String class. Ah, but FSPathMakeRef() is useless. So where else do I look for an OS 9-10 compatible method to achieve this? >From MacOSX.com response: 1) Use the File Manager functions to locate the files. 2) Call FSpOpenResFile to open the file and read its resource map into memory. http://developer.apple.com/document...n_group_12.html 3) Use a function like Get1Resource to read the resource data http://developer.apple.com/document...00154/TPXREF116 4) Close the resource file And so far I agree with the general approach, but getting from A->B in Step 1) is not being well explained, nor demonstrated, nor documented. If it is, it is well hidden. Robert How about this (general): [Do something to get an FSRef] FSOpenFork() FSReadFork() FSCloseFork() Will this work or are these for other purposes? Robert > How about this (general): > [quoted text clipped - 4 lines] > > Will this work or are these for other purposes? nope, won't work. if you go that route, you could get access to the raw bytes in the resource fork, but not the actual resources. to interpret the raw bytes as resources, such as bitmaps and so on, you need the resource manager. i am certainly no expert at this stuff, but about a year ago i was in the same boat you're in, i.e., total mac newbie, and i wanted to read and write resources to a file. the trouble is that resource manager is designed to solve an entirely different type of problem than the one you've got. your question is "i'd like the resources in this file," but the resource manager doesn't work that way. it's designed to answer questions such as "i'd like to lay my hands on a particular resource, i don't care if it belongs to a particular file, to my app, or to macos itself, just give it to me." there's really nothing for it but to play along with the resource manager. what i did was make my file's resource fork the "current" one just before i attempted any particular i/o operation. it took a lot of coding and thinking on my part to come around to seeing things the right way, but i got it, eventually. it means "halo, then resonate" Jøhnny Fävòrítê wrote: > nope, won't work. if you go that route, you could get access to the raw > bytes in the resource fork, but not the actual resources. to interpret > the raw bytes as resources, such as bitmaps and so on, you need the > resource manager. See, they don't clarify that very well, which is why I asked. ;) > i am certainly no expert at this stuff, but about a year ago i was in > the same boat you're in, i.e., total mac newbie, and i wanted to read [quoted text clipped - 5 lines] > don't care if it belongs to a particular file, to my app, or to macos > itself, just give it to me." This I do understand from what I've read. Yes, I can't ask for the 'resources in this file', but they sure go around the real question very circumspectly. > there's really nothing for it but to play along with the resource > manager. what i did was make my file's resource fork the "current" one > just before i attempted any particular i/o operation. it took a lot of > coding and thinking on my part to come around to seeing things the right > way, but i got it, eventually. Well, my most dire problem right now is getting a path string like: "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so that I can at least start by making the file's resource fork the 'current' one. FSPathMakeRef() will not work in OS 9. I quote: *** Special Considerations: This function, though available through Carbon on Mac OS 8 and 9, is only implemented on Mac OS X. Availability: Available in CarbonLib 1.1 and later. Available in Mac OS X 10.0 and later. *** I cannot find anything else that does this that works back to OS 9.x. In order to make the file's resource fork current, I at least need a way to convert it into something that these functions understand. Every search I do leads to MacOSX, Bundles, Cocoa, stuff that will not work in this situation. > Well, my most dire problem right now is getting a path string like: > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 8 lines] > Mac OS X 10.0 and later. > *** can't help you with that, i'm afraid! all the code i've written is for macosx only. sorry. > Well, my most dire problem right now is getting a path string like: > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 8 lines] > X 10.0 and later. > *** That's pretty confusing. If it's available in CarbonLib 1.1 and later, that certainly implies that it is implemented in OS 9. Can you assume OS 9.1 or later? APIs that use the FSRef data type generally require OS 9.1. Another API you might look at is CFURLCreateWithFileSystemPath. > Well, my most dire problem right now is getting a path string like: > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so > that I can at least start by making the file's resource fork the > 'current' one. FSPathMakeRef() will not work in OS 9. FSMakeFSSpec gets you halfway there. There _may_ be a direct route, but that's the one I know off the top of my head. You should be aware that pathnames are not unique identifiers in Mac OS. G SignatureChange account to gw when responding by mail. > > Well, my most dire problem right now is getting a path string like: > > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 3 lines] > FSMakeFSSpec gets you halfway there. There _may_ be a direct route, but > that's the one I know off the top of my head. There is MoreFiles, which provides all the from/to full path under Mac OS and Carbon: <http://developer.apple.com/samplecode/MoreFiles/MoreFiles.html> Thorsten > Well, my most dire problem right now is getting a path string like: > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so > that I can at least start by making the file's resource fork the > 'current' one. Use CoreFoundation. Create a CFStringRef containing your path. Create a CFURLRef from that string, treating the string as an HFS path. Then get the FSRef for that URL. -- Chris > > Well, my most dire problem right now is getting a path string like: > > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 6 lines] > string, treating the string as an HFS path. Then get the FSRef for > that URL. I believe CFURLGetFSRef calls FSPathMakeRef. If FSPathMakeRef doesn't work on 9 -- which is unclear from the latest comments in this thread -- CFURLGetFSRef won't work either. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ >> your question is "i'd like the resources in this file," but the resource >> manager doesn't work that way. it's designed to answer questions such as "i'd >> like to lay my hands on a particular resource, i don't care if it belongs to >> a particular file, to my app, or to macos itself, just give it to me." > This I do understand from what I've read. Yes, I can't ask for the > 'resources in this file', but they sure go around the real question > very circumspectly. It does work that way if you set the current resource file and use Get1Resource. Get1Resource will fail if the resource isn't in the current resource file. Larry > Well, my most dire problem right now is getting a path string like: > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so > that I can at least start by making the file's resource fork the > 'current' one. Well unfortunately you'll have to parse the file name into components and navigate through the file system one level at a time, building an FSSpec or FSRef as you go. It may seem like a pain in the neck, but storing file information as hard-coded paths is not the way things are supposed to be done on the Mac. Under OS 9 this can be particularly problematic because all volumes are at root level and are not required to have unique names, so a full path name can be ambiguous. The Mac OS provides aliases which are a much better way to keep persistent references to files. However this doesn't help you. If the software hosting your plug-in insists on using an unreliable least-common-denominator method to identify files, that's what you have to deal with. Parse the string. Enumerate the volumes to find the one at the head of your path. Make an FSRef to the first directory. Make an FSRef to the next directory... > Well unfortunately you'll have to parse the file name into components and > navigate through the file system one level at a time, building an FSSpec or [quoted text clipped - 12 lines] > path. Make an FSRef to the first directory. Make an FSRef to the next > directory... I've come to that conclusion also (from the no-unique-names info). Yes, the hosting software's SDK has no support for anything system-dependent. It can tell you information about which system you are using and, internally compensates for all of the details, but that's about it. I have no access to these details (nor would I want to). And the entire problem is that the 'donor' application (the one whose files have these PICT resources for creating thumbnails and which originated on MacOS) uses the resource fork to store the PICT resource. It has other methods not using resource forks (PNG, PCT, JPG, RSR), but these are not always options on MacOS. With Windows, if none of these files exist, there is no thumbnail. Now, let's say that I've converted the path string into an FSSpec, used that with FSpOpenResFile() - I'm hoping that 'fsRdPerm' is the correct permission, and have called Get1Resource('PICT', id). How can I use the returned Handle (another seemingly ubiquitous euphemism) to save the PICT data out to a PCT file? Unless there is something impossible about it, I'll be using SDK functions to write the data as a Bytes buffer. I also know about the 512-byte 'header' on the PICT format. Thanks, Robert > Now, let's say that I've converted the path string into an FSSpec, used > that with FSpOpenResFile() - I'm hoping that 'fsRdPerm' is the correct > permission, and have called Get1Resource('PICT', id). All correct. > How can I use > the returned Handle (another seemingly ubiquitous euphemism) to save > the PICT data out to a PCT file? Unless there is something impossible > about it, I'll be using SDK functions to write the data as a Bytes > buffer. I also know about the 512-byte 'header' on the PICT format. Handles were devised to allow for memory blocks to be able to move on small-RAM no-VM systems. Unlike 32-bit versions of Windows, you do have to actually double-dereference to get at the data, and under OS 9 if not locked they really can move any time you call a function that might allocate memory. Other than that, you just write out the header, something like: // get the handle from the resource file FSpCreate... ref = FSpOpenDF... long len = 512; FSWrite( ref, &len, theHeader ); long len = HandleSize( thePictHandle ); HLock( thePictHandle ); FSWrite( ref, &len, *thePictHandle ); FSClose( ref ); ReleaseResouce( thePictHandle ); Bear in mind that it's been 10 years since I created a PICT data file ;-) Also note that if you stick with FSSpec's, you won't be able to navigate through any folders with names longer than 31 characters. Of course if the hosting application uses FSSpec's, then you may not care. > > Well, my most dire problem right now is getting a path string like: > > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 4 lines] > navigate through the file system one level at a time, building an FSSpec or > FSRef as you go. Hm? FSPathMakeRef should do this in one call. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > Well, my most dire problem right now is getting a path string like: > > > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 12 lines] > Eric Albert ejalbert@cs.stanford.edu > http://outofcheese.org/ Does FSPathMakeRef work in OS9? \Looks at documentation for 5000th time\ NO! See, confusing isn't it? ;) Robert > Does FSPathMakeRef work in OS9? \Looks at documentation for 5000th > time\ NO! When in doubt, try it. I tried FSPathMakeRef and FSRefMakePath under OS 9.2.2 with CarbonLib 1.6, and they worked. > > Does FSPathMakeRef work in OS9? \Looks at documentation for 5000th > > time\ NO! > > When in doubt, try it. I tried FSPathMakeRef and FSRefMakePath under > OS 9.2.2 with CarbonLib 1.6, and they worked. But I can't try it. I'm on OS 10.3.7. The application won't run in Classic mode if OSX is available. Anyway, I would want to see it on an OS 9 only system before removing doubt. :) Robert > But I can't try it. I'm on OS 10.3.7. The application won't run in > Classic mode if OSX is available. It should be possible to make it run in Classic. If you Get Info on the application's icon in the Finder, you should see a checkbox "open in the Classic environment". (It may be necessary for the application to have a unique creator code in order for this to work.) > Anyway, I would want to see it on an > OS 9 only system before removing doubt. :) That's reasonable. Great Scott!!!!! (needs more exclamation points!!) (=0) That did the trick. I now have all of the resource fork PICT thumbnails showing in my plugin. Thank you and I'm certain that my Mac users will thank you also! Robert Great Scott!!!!! (needs more exclamation points!!) (=0) That did the trick. I now have all of the resource fork PICT thumbnails showing in my plugin. Thank you and I'm certain that my Mac users will thank you also! Robert > > Well, my most dire problem right now is getting a path string like: > > "HD:folder:folder:folder:folder:file.xxx" converted into a FSRef so [quoted text clipped - 4 lines] > navigate through the file system one level at a time, building an FSSpec or > FSRef as you go. No you don't. The fileName arg to FSMakeFSSpec will take a full path. G SignatureChange account to gw when responding by mail. > No you don't. The fileName arg to FSMakeFSSpec will take a full path. Argh. Yes, as long as the path is 255 characters or less. I guess I was thinking of the other route, starting with an FSSpec and deriving the full path name, something which Apple didn't support directly, probably deliberately. I almost forgot: you can use this email instead (I know that I'll regret this - thank jove for their spam filter): so_clu_less@yahoo.com Addendum: I'm not trying to be offensive or anything, just trying to get a concise answer to what should be a straight forward approach. MacOS resource forks are/were the foundation bedrock of the filesystem - why are they so nontrivial and elusive critters? Robert > I almost forgot: you can use this email instead (I know that I'll > regret this - thank jove for their spam filter): so_clu_less@yahoo.com [quoted text clipped - 5 lines] > > Robert You'd probably be best checking out "Carbon Programming" by Bricknell, it was exactly what I needed for a project doing essentially the same thing. You can download it at: http://www.mactech.com/macintosh-c/ Or buy a print copy off of amazon. > > I almost forgot: you can use this email instead (I know that I'll > > regret this - thank jove for their spam filter): so_clu_less@yahoo.com [quoted text clipped - 8 lines] > You'd probably be best checking out "Carbon Programming" by Bricknell, > it was exactly what I needed for a project doing essentially the same > thing. > > You can download it at: http://www.mactech.com/macintosh-c/ > Or buy a print copy off of amazon. Thank you very much!! I'm trying to avoid books (have hundreds already), but if it has valuable resources, there is always more room on my wall of shelves. ;) And please try my email again as I've done some 'configuration' changes. This sucker (ASSP for those who know it) is tough. All I get access to is the basic HTML configuration screen (which doesn't allow full configuration), so I've done what I could to get emails directed to me to bypass the filter altogether (let's see if it works - otherwise, I'm going ape!). At this point I don't care about 1000 spams as long as the 20 or 100 valid emails get through. What a pita! Robert > I almost forgot: you can use this email instead (I know that I'll > regret this - thank jove for their spam filter): so_clu_less@yahoo.com [quoted text clipped - 3 lines] > MacOS resource forks are/were the foundation bedrock of the filesystem > - why are they so nontrivial and elusive critters? a) I don't agree that there were the foundation or bedrock of the file system. They were a supported and simple way to store structured data in a very simplistic database. They were, in fact, a fairly late addition. b) IMO, if you're finding them "nontrivial and elusive" you're probably overthinking things. For most users, handling the resource fork boils down to three calls: Open the resource fork, load a resource by type and ID, close the resource fork. And the open/close pair aren't necessary if the resource fork in question is the one linked to the app binary itself. G SignatureChange account to gw when responding by mail. dans l'article macdev-7BA45F.19220320012005@unknown.astraweb.com, Miro Jurisic à macdev@meeroh.org a écrit le 21/01/05 1:22 : >> Yes. That's what it was designed for in the first place: work in both Mac0S >> 9 and MacOS X. [quoted text clipped - 5 lines] > of > Carbon that are only available on Mac OS X. I wrote: "in the first place". Keeping Carbon alive was not the initial intention. But since very few developers have switched to Cocoa, which by the way does not provide all you need, Apple changed ther mind. Eric I should have pointed out that it is possible that the hosting application will make sure your plug-in is at the head of the resource search path before calling into your plug-in, in which case it is a simple matter of calling GetResource. If not, then you may wish to locate your own plug-in and set the resource file. That assumes that you are building your plug-in as a single executable file with a resource fork, and not packaging it as a bundle. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.