Accessing resources in a bundle

NSBundle has this method:
- (NSString *)pathForResource:(NSString *)name ofType:(NSString *)extension
As the first argument, you pass the name; the second is the name extension (e.g. the first arg is @"Dictionary" and the second @"plist"; would require a file name Dictionary.plist).

So you could access your file (stored in Foo.app/Contents/Resources) like this:

NSString * fullPathToFooBar = [[NSBundle mainBundle] pathForResource: @"Foo" ofType: @"Bar"];
// you now have the full path of Foo.bar; you can use NSFileManager to do your thing.

Hope this answers your question.

Thank you! This is what I was looking for! May I ask you one last question? Is there an equivalent of the system() call in cocoa? I'd like to call Preview.app within my program and as of now I make some jump around with system() and "open"...thanks again for the reply!

Of course.  You can use system() - Obj/C is C - so all of the standard C (and std C++) library is available.  However, you'll probably prefer NSTask as being a much more "Cocoa-centric" way of doing things.  Until you feel good about using NSTask, you might prefer to use something like this:

NSString* openMyPDF = [NSString stringWithFormat:@" open foo.pdf"];
NSLog(@"about to run cmd %@",openMyPDF);
system([openMyPDF UTF8String]);

I don't remember off the top of my head how to use NSTask - however it's almost equally painless.  NSTask of course supports unicode strings - system() and the other standard C functions expect char* (which I think are UTF8s).

Thanks for the pointer! The system() call is what I am implementing at the moment...what I like of obj-c is that when I get lost (which occurs more often than I would admit) I can try to work around in plain C, if the task allows. However, I would like to make my code more "cocoa-centric" as you say :) I bet I should buy some book and get started with it. Any good suggestion?

Thanks for all guys!

If you want to lean Obj/C, Stephan Kochan's book's very good.  However if you know C, you'll probably find that not doesn't take you as far as you'd like to go.

When you want to learn "the Cocoa Way", Aaron Hillegass' book's the one I recommend.  Until recently, it was about the only book, however the arrival of the iPhone and the iPad has changed the landscape and there are a number of books to choose from.

I'm sure my buddy K will want to add his thoughts about this.

The Apple documentation is very good - however it takes a while to become accustomed to it.  Have a sniff at the NSTask class in the help system.  If you're not sure what to do, com'on back and ask and we'll try to help.

Correct. I own both books clanmills has mentioned -- they're both excellent for their purpose.

Check out the NSTask Class Reference. You could use this (untested):

NSArray * args = [NSArray arrayWithObjects:@"/Users", @"/Applications", @"/System/Library"];
NSTask * sysTask = [NSTask launchedTaskWithLaunchPath:@"/usr/bin/ls" arguments:args];
// wait…
if (![sysTask isRunning]) {
    NSPipe * outPipe = [sysTask standardOutput];
    // do stuff with the pipe
}

Thanks for all the suggestions! I did it, Cocoa way :) BTW, the project is here

http://www.fisica.unige.it/~cavaliere/soft/MacIsing.zip

if anybody wanted to have a look :) Thank you for all the support and...I will maybe ask some more question in the future :)

Wow, that's strange! What is it for?

Indeed, documentation has to be (re)written :) 

That's a simulation of a (highly idealized) 2D model for a magnet (Ising model). There is a square lattice of "spins" (tiny magnetic dipoles, as the needle of a compass) which can either point up or down (yellow or red squares). Each spin interacts with the 8 spins surrounding it, with a strength set by J (nearest neighbours) and Jnn (next-to-nearest neighbour). Spins can also be "shaken" randomly by temperature (T) and tend to align if a magnetic field (B) is applied. Basically, the program simulates how the spins will eventually arrange at given parameter configurations. If one would accumulate statistics out of the simulation, several quantities of physical interest could be calculated. I decided not to do that and to second the "visualization" aspect.

The rendering taught me a lot about Cocoa. My first attempt was to create 200x200 NSViews (each tiny box) and then dinamically change their colour. Horribly slow, lots of memory consumption. Then, a friend of mine told me about subclassing a single NSView. Much better! But still, in drawRect() each rectangle was drawn with NSMakeRect, with rather sluggish performance. The final approach (as of now) is to draw the view off-screen into a bitmap (so I basically draw on a pixel-per-pixel basis) and then to blit the bitmap onto the NSView. *Bam!* Much, much faster! :)

Also, I was amused to find how easy is to fork a thread in Cocoa. I am used to vanilla pthread stuff on shared-memory machines and all the cumbersome procedures to actually fork and join...In this respect, Cocoa is just great!

Fabio

Thank you for sharing this with us.  For sure it looks real good.  Of course I know nothing about the problem domain.  To me, a magnet is a thing my wife uses to stick my TODO list to the fridge door.

I was interested in your comments about rendering.  I wrote a CAD system years ago (not on the Mac) and use off screen buffering as part of the rendering.  I'm sure millions of NSViews will eat both your memory and be very slow.  Rendering to a frame buffer and BLTing to the screen's the way to get good graphics performance.

One of my cocoa tutorials is a QuartzClock and has a considerable discussion about PostScript and it's relationship to the the Quartz Imaging Model used by the Mac  http://clanmills.com/articles/cocoatutorials/

And yes, tasking and threading in Cocoa are very straightforward.  In fact, almost everything in Cocoa is straightforward - however many of the design patterns are not familiar to most new users.  So Cocoa has a learning cost, followed by a big productivity win.

Thank you once more for sharing this with us.

A magnet is what they hide on mini-putt courses to make sure you don't sink your ball. :)

That many NSView's are evil. Think of having 300 kids manage a task easily done by one adult.

Indeed, you have to learn a bit before you become "good" at Cocoa. It's actually elegant once you learn it.

Now I can see why you wanted the bundle access -- the PDF file is accessed from the Help menu.