 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / June 2005I just wanted to open a file in 10.4 api!
Hi, I need to change from FSpOpen (deprecated) to FSOpenFork so I can comfortably make a universal binary that will last for years. But FSOpenFork uses uni code. What's the easiest way to open "myfile.txt" in the application directory? It seems too complicated to convert from a C string to uni code just to use FSOpenFork, I must be looking at it from the wrong perspective. Any help appreciated. ---------------------- I've got:- ProcessSerialNumber PSN; FSRef fsRef; OSStatus err; PSN.highLongOfPSN = 0; PSN.lowLongOfPSN = kCurrentProcess; /* grab the vrefnum and directory */ err = GetProcessBundleLocation(&PSN, &fsRef); #if(0) OSErr FSOpenFork ( const FSRef * ref, UniCharCount forkNameLength, const UniChar * forkName, SInt8 permissions, SInt16 * forkRefNum ); #endif ------------------ Thanks, Paul On 22/06/2005, pf wrote in message <42b90c4b$0$860$61c65585@uq-127creek- reader-03.brisbane.pipenetworks.com.au>: > I need to change from FSpOpen (deprecated) to FSOpenFork so I can > comfortably make a universal binary that will last for years. But > FSOpenFork uses uni code. What's the easiest way to open "myfile.txt" > in the application directory? It seems too complicated to convert from > a C string to uni code just to use FSOpenFork, I must be looking at it > from the wrong perspective. Forks are deprecated. Carbon is deprecated. If you're worrying about 'last for years' then you should be handling bundles, not forks, and writing in Cocoa, not Carbon. In Cocoa and you can read or write a Unicode text file in one instruction and Xcode will compile your application into a universal binary for you. Here's how to read a text file in Cocoa (all one long line): NSString *myText = [[NSString alloc] initWithContentsOfFile:@"~/Documents/myfile.txt"]; Here's how to ask the user for a filename and create that file with your text in: NSString *myText = @"Hello world." NSString *filename = [savePanel filename]; if (![myText writeToFile:filename atomically:YES]) NSBeep(); The second example includes error-trapping: it beeps if the write failed. You shouldn't do either of these things exactly the way I used, but I'm trying to show you how simple it is to do what you want. And, of course, everything's in Unicode. 'last for years'. Simon.  SignatureUsing pre-release version of newsreader. Please tell me if it does weird things. In article <d9kcnk$q6$2$830fa7a5@news.demon.co.uk>, Simon Slavin <slavins.delete.these.four.words@hearsay.demon.co.uk> wrote: > Carbon is deprecated. Would you please stop spreading this misinformation! Nowhere has Apple stated it as deprecated! > Would you please stop spreading this misinformation! > > Nowhere has Apple stated it as deprecated! I think he was just being overly dramatic. The truth is that Cocoa is far more advanced than Carbon, and all new application development should be for Cocoa, not Carbon. Carbon is only being supported as a legacy. |\/| /| |2 |< mehaase(at)sas(dot)upenn(dot)edu >> Would you please stop spreading this misinformation! >> [quoted text clipped - 4 lines] > should be for Cocoa, not Carbon. Carbon is only being supported as a > legacy. Yes, unless your new application needs to use global hotkeys, discover properties about LSUIElement applications, run in kiosk mode, prevent the system from going to sleep.... and that's just off the top of my head. Oh, and don't forget all the bits of Cocoa that are built on top of Carbon, such as NSMenu. Strange that they'd use Carbon if it were only for legacy. When it gets to the point where you never have to touch Carbon to accomplish things that aren't Carbon-specific, then we can talk about Carbon only being for legacy. Until that time, you should recognize Carbon and Cocoa for what they really are: co-equal APIs which are both actively developed and supported by Apple, with differing strengths and weaknesses and different areas of specialty. > On 22/06/2005, pf wrote in message <42b90c4b$0$860$61c65585@uq-127creek- > reader-03.brisbane.pipenetworks.com.au>: [quoted text clipped - 7 lines] > > Forks are deprecated. Carbon is deprecated. You keep using that word. I do not think it means what you think it means. Apple has not officially discouraged people from using Carbon, nor have they announced that it is likely to disappear at any moment in future OS releases. Thus, Carbon is not deprecated. > Here's how to ask the user for a filename and create that file with your > text in: [quoted text clipped - 3 lines] > > if (![myText writeToFile:filename atomically:YES]) NSBeep(); You forgot the code required to actually set up and run the save panel. If you're using it as a sheet, which you probably should be, then this code is fairly complicated and involves non-linear code flow. I think Cocoa is the best thing since sliced bread, but these kinds of exaggerations and outright falsehoods do not serve to attract people to it, but rather the exact opposite. By all means talk about how Carbon is old and crusty, and demonstrate how easy it is to put up a save panel and save a file, but don't claim that Carbon has been deprecated or leave out all of the important parts of the file-saving code; such tactics don't help anybody. > Carbon is deprecated. Carbon is not deprecated. -- Chris On 25/06/2005, Chris Hanson wrote in message <2005062517235516807%cmh@maccom>: > > Carbon is deprecated. > > Carbon is not deprecated. Thanks to you and to others in this thread for the correction. Simon. SignatureUsing pre-release version of newsreader. Please tell me if it does weird things. |
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.