macOS NSApplicationMain: What happens to parameters?

[ajbrehm]

Well you don't have to do it that way. You could have your instance set itself as the application delegate programatically when it wakes from the bib. Or do you mean the way you do the connection? As that's covered in the tutorials. You eventually think it's second nature!

I might not use Cocoa often enough to develop a second nature for that. I usually use Visual Studio.

What I am trying to do on the Mac is write a wrapper for .NET applications (using Mono). I did something similar for Darwin applications a few years ago. I was completely surprised by how Cocoa wanted me to handle files I double-click on.

 

[ajbrehm]

Well you don't have to do it that way. You could have your instance set itself as the application delegate programatically when it wakes from the bib. Or do you mean the way you do the connection? As that's covered in the tutorials. You eventually think it's second nature!

It works now, but only for the text field. When I try to assign the string filename to another NSString in the program, the program crashes.

Specifically, what works is:

[someTextField setStringValue:filename];
NSString *anotherString = filename;
someGlobalString = @"Hello, world";

And what doesn't work is:

someGlobalString = filename;

With "someGlobalString" being defined for the entire class.

Any ideas?

 

[ajbrehm]

I just noticed that I can write the string filename into a text field and then read it from there into a class variable.

I.e. this doesn't work:

someGlobalString = filename;

But this does:

[someTextField setStringValue:filename];
someGlobalString = [sometextField stringValue];

 

[Nutter]

This is most likely a memory management issue. The filename variable was autoreleased before it was passed to you, which means that it will automatically be deallocated at some point in the (near) future.

As you assign the filename to your global variable you should retain it, to indicate that you don't want it to be deallocated. Like so:

someGlobalString = [filename retain];

Having done this, you are now responsible for releasing the object when you have finished with it. In other words, if you want to change the string that your global variable points to you should first release this string. I've edited Robbie's project and am attaching a new version to show what I mean.

Note that unless you have a really good reason to use a global variable it's better to add an instance variable to your object and write an accessor method to access the path from other parts of your app.

 

[Eraserhead]

Rather than setting the pointer to the old string, it might be better to use newString=[NSString stringWithString:filename];

Remember with Cocoa some stuff will be worse than VS and some stuff better, and some stuff just different, you'll have to just get used to it .

 

[robbieduncan]

As that is not an alloc/init or copy call I would expect that to return an autoreleased string too. This will result in the same errors as before. Personally I have no issue with retaining the original string, but it you want to create a new string copy of it you'll have to retain it (or use it in the this run loop only)...

 

[Nutter]

... or use [filename copy], which is a more obvious way of creating a copy and gives you ownership of the object.

However, NSString (like other immutable Cocoa objects) implements -copyWithZone: to just call -retain, because a copy of an immutable object can never be any different from the original.

That's why I just retained the original string in my code, but yes, from a semantic point of view someGlobalString = [filename copy]; is more correct.