macOS Asking for Clarification about a few issues

[mdeh]

Good morning all,

I am working through an example that demos the use of multiple nibs/controllers.

The initial controller is initialized in code thus, in the AppDelegate.m file . (GC enabled).

#import "HelloApplicationAppDelegate.h"
#import "MyWindowController.h"



@implementation HelloApplicationAppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    
    [[MyWindowController alloc]initWithWindowNibName:@"MainWindow"];
    
        
}

So, I have a couple of questions.

1) It would seem that the initialization/allocation( in the delegate method "applicationDid.....") would simply be released at the end of the function. Yet, the example works as expected. What am i missing?

2) Is it possible to do the same in IB i.e. declare an object of class "MyWindowController". If so, how to associate this with the nib named "MainWindow" or is this simply poor programming style?

Thanks in advance?

 

[robbieduncan]

Objects that are not autoreleased are not released for you at the end of the current run loop. As you are calling alloc/init you "own" that object and are responsible for releasing it.

Note this somewhat assumes you don't have garbage collection turned on.

 

[mdeh]

Objects that are not autoreleased are not released for you at the end of the current run loop. As you are calling alloc/init you "own" that object and are responsible for releasing it.

Note this somewhat assumes you don't have garbage collection turned on.

Thanks Robbie, that makes perfect sense. And since GC is turned on ( in this case) there is no need to release it?

Now, could I try and clarify the second issue. ( I am assuming this would **not** be a good way to do this, but for my own understanding).

Let's say I now wish to do the same by having a MyWindowController object in a nib(in this case "MainMenu.nib) , whose File's owner ( in this case ) is "NSApplication". Where I get stuck is how to associate this object with the nib named "MainWindow".
This has come up in other ways, but the conceptual basis of my question would be the same.

Again, thank you.

 

[robbieduncan]

Thanks Robbie, that makes perfect sense. And since GC is turned on ( in this case) there is no need to release it?

I've never used Cocoa with GC

I'd be worried that since you don't assign it to an ivar it would get collected at some point

 

[ChOas]

Good morning all,

I am working through an example that demos the use of multiple nibs/controllers.

The initial controller is initialized in code thus, in the AppDelegate.m file . (GC enabled).

Wow... This is new to me, don't you need to assign your controller to something ? How are you going to refer back to it (is it's not a singleton) ?

 

[mdeh]

Wow... This is new to me, don't you need to assign your controller to something ? How are you going to refer back to it (is it's not a singleton) ?

You are not the only one that was perplexed. But, the controller never, as far as I can tell, needs to be referred to again, I suspect, as it is released by the GC management system.

 

[Catfish_Man]

If an object in a GC app is not reachable by pointer traversal from a root (the stack, a global/static variable, etc...), it will be collected. You can use 'info gc-roots' in gdb to print out what's rooting an object if it's not being collected.

 

[mdeh]

If an object in a GC app is not reachable by pointer traversal from a root (the stack, a global/static variable, etc...), it will be collected. You can use 'info gc-roots' in gdb to print out what's rooting an object if it's not being collected.

Does the fact that this WindowController, during it's initialization has references to a Window, other ivars etc thus prevent it from being immediately collected?

 

[chown33]

Does the fact that this WindowController, during it's initialization has references to a Window, other ivars etc thus prevent it from being immediately collected?

No.

If I paste a link to www.apple.com into this post, then this post refers to that page. So as long as this post exists, there is a reference to that page. The reference is one-directional, unless you put a link to this post on that page.

I think you should re-read the Garbage Collection and Memory Management programming guides.

 

[jiminaus]

1) It would seem that the initialization/allocation( in the delegate method "applicationDid.....") would simply be released at the end of the function. Yet, the example works as expected. What am i missing?

An NSWindowController will add itself as an observer of the NSWindowWillCloseNotification posted by the NSWindow connected to the NSWindowController's window outlet. This reference alone would be enough to keep the NSWindowController alive.

There might also be other connections in the NIB also keeping the NSWindowController alive.

2) Is it possible to do the same in IB i.e. declare an object of class "MyWindowController". If so, how to associate this with the nib named "MainWindow" or is this simply poor programming style?

Now, could I try and clarify the second issue. ( I am assuming this would **not** be a good way to do this, but for my own understanding).

Let's say I now wish to do the same by having a MyWindowController object in a nib(in this case "MainMenu.nib) , whose File's owner ( in this case ) is "NSApplication". Where I get stuck is how to associate this object with the nib named "MainWindow".
This has come up in other ways, but the conceptual basis of my question would be the same.

It is possible. In my early days of Cocoa programming, I used to add a window controller custom object to my MainMenu.xib. I overrode init in MyWindowController to call [super initWithWindowNibName:@"MainWindow"].

While I do still override init and make it MyWindowController's designated initializer, I don't add it to MainMenu.xib. It's not flexible enough in long run. For example, it doesn't migrate to higher-level architectures such as the NSDocument-based architecture.

 

[mdeh]

An NSWindowController will add itself as an observer of the NSWindowWillCloseNotification posted by the NSWindow connected to the NSWindowController's window outlet. This reference alone would be enough to keep the NSWindowController alive.

There might also be other connections in the NIB also keeping the NSWindowController alive.






It is possible. In my early days of Cocoa programming, I used to add a window controller custom object to my MainMenu.xib. I overrode init in MyWindowController to call [super initWithWindowNibName:@"MainWindow"].

While I do still override init and make it MyWindowController's designated initializer, I don't add it to MainMenu.xib. It's not flexible enough in long run. For example, it doesn't migrate to higher-level architectures such as the NSDocument-based architecture.

Thank you to all who have enlightened.