Related
On Yosemite,When you create a simple document-base app using Xcode's template,you will get a storyboard which contains a windowController object and a customized NSViewController object and the former's contentViewController is the Latter(by a triggered segues connection).Then you can write a subclass of NSWindowController and set it as the windowController object's class.
Launch the App and it shows a empty window,close the window,you will find the NSWindowController object and the window object are all dealloc(by overriding their dealloc methods),but the ViewController object is still alive! And when you set the NSWindowController.contentViewController as nil in it's dealloc method, the ViewController object is dealloc finally. I think it's a bug of Yosemite.Am I right?
I notice the Mac App template has create the following:
#interface AppDelegate : NSObject
#property (assign) IBOutlet NSWindow *window;
According to the ARC guidelines all top level object should use a strong property but instead this is using an assign property. Would someone explain why?
A window will generally be "owned" by File's Owner, which will usually be your NSApplication instance (for the main nib) or an instance of NSWindowController, not necessarily the app delegate or the window delegate. This is why it wouldn't be appropriate for the reference to be strong inside the delegate class.
In Mac OS/X 10.7, NSWindow (along with several other Cocoa classes) didn't support management via ARC, so declared properties to NSWindow had to be assign rather than strong or weak. See the Transitioning to ARC and Nib Object Life Cycle documents for a more detailed discussion. The basic answer is that you can't use ARC-managed references for objects that override the release and retain methods.
In 10.8, it looks like NSWindow isn't on that list, but Xcode is still generating the assign attribute rather than weak.
By using of Xcode 5 and auto-reference counting is enabled.
In a Non NavigationController based application i have take a UIButton and the IBAction and IBOutlet are properly defined and connected. But before the IBAction for TouchUpInside event called by Button taped the App gives "[SecondPage performSelector:withObject:withObject:]: message sent to deallocated instance 0x6cb7970".
SecondPage is view-controller on which this UIButton exists.
Basically I want to open a new view-controller's view on this UIButton tapped and i will do this by Custom Segue
Hmm strange it sounds like ARC is autoreleasing your secondView controller before your selector is being called.
Try defining your secondView as a property of the first (if you're adding it as a subview) with a property type of strong.
That's all I can recommend without seeing your code.
I was getting same problem and solved with what Matt Rees suggested.
Just declair your secondViewController in firstViewController.h and made its instance there. Like,
secondViewController *secondView;
I was getting same problem and solved with what error thrown.
With more details, I was reallocating caller object (SecondPage in this case) on logout/login, but re-using some other viewcontrollers, so re-used viewcontroller have previous instance of caller object that I reallocated.
Well, solved it now!
I know some mechanism of outlet connection when loading NIB, but I am not sure. So I'm asking some questions to ensure my knowledge. I assumed these things all true, but It's hard to find mention about these on reference documentation. Please point wrong and right things.
I have an IBOutlet defined like this: (Of course it's not recommended way)
#implementation
{
IBOutlet id var1;
}
#end
NIB loader (alloc | retain) & autorelease all top-level objects. So it will be dealloc on runloop turn ends without additional retain.
Connecting IBOutlets are done with KVC.
KVC uses accessor method primarily.
KVC uses setValue:forKey secondarily. And the IBOutlet will be handled by this method because there's no declared property or access method.
setValue:forKey retains the new value object.
setValue:forKey releases the old value object.
So top-level object connected to the IBOutlet will be retained once. So I have to release it to dealloc. This is why I must release objects connected to IBOutlet on dealloc method.
If the object connected another IBOutlet like the IBOutlet, it should be released once more to be dealloc.
When a Cocoa NIB file instantiates an instance of a custom controller object, what is the name of the variable that that custom controller instance is assigned to?
In case that isn't clear, if you manually created an instance of that class you would do:
MyControllerClass *myVar = [[MyControllerClass alloc] init];
What equivalent of "myVar" has the NIB used when doing this behind the scenes?
There is no such thing as a variable name once the app is compiled, so this question doesn't make much sense. In your example, myVar is just a convenient label for you, the programmer, and does not exist in any way once your source code is compiled into binary code.
When you place an object into a nib file, it is archived and then unarchived at runtime. If you want to be able to get a reference to an object that has been archived in a nib file, you need to use an outlet, which means you declare an IBOutlet instance variable in a class that is present in the nib file and then connect that outlet to the object in the nib you want to reference in Interface Builder. Instance variables are different to the stack variable that you declared in your example and can be referred to at runtime.
Typically you would have an object that "owns" a nib. Normally nibs are loaded by an instance of NSWindowController or NSViewController and window or view controller is represented in the nib file as File's Owner. If you declare outlets in your window/view controller, you can then connect the outlets from File's Owner to your object in Interface Builder.
So, to clarify, you need a reference to your object in the nib from some other object in the same nib. That second object declares an outlet using the IBOutlet keyword on an instance variable like so:
#interface SomeOtherObject : NSObject
{
IBOutlet SomeObject* anObject;
}
#end
In Interface Builder, you can then connect the anObject outlet of the SomeOtherObject instance to the first SomeObject instance. You can do this by control-dragging from one object to another or you can do it in the connections panel in the Interface Builder inspector.
You can then refer to your SomeObject instance by the variable name anObject inside the code for SomeOtherObject.
Implement the awakeFromNib method in your controller class - it's called immediately after the nib has finished loading, and your controller's instance can be found in the "self" variable.
# tedge (I can't make comments to your answer):
Can you clarify for a beginning Cocoa learner a bit. Take the Apple Currency Converter tutorial.
I implement the awakeFromNib method in the existing ConverterController class. (Something I will be learning to do shortly!)
The app starts up and an instance of ConverterController is automatically instantiated.
What will awakeFromNib tell me about that running instance (other than that it's ready to use) -- and what syntax with "self" gets it to divulge that information?
… what is the name of the variable that that custom controller instance is assigned to?
It's whatever name you gave that variable when you declared it.
IB doesn't create variables for you. It sounds like you're after an outlet, which is a variable you create that IB knows about and lets you plug objects into, thereby setting the variable.
(You actually can create outlets from IB, and in the modern runtime, this should really create the outlet, not just declare a non-existent outlet in the nib. Even this way, though, you create the outlet [in IB] and you give it a name.)
I think what's Nibbles is confused about is that how to reference the variable defined only in NIB file from code.
the answer to that is, normally you have a custom controller class (or delegate class) A in code and NIB, and if you have another class or controller B only defined in NIB, just setup a outlet in A pointing to B. Since A can be used anywhere in your code, B can be accessed as well through A then.
I had this question as well.