Misunderstanding
Hi.
I think there's a misunderstanding, Darkroom. When i write :
First of All, in the Interface Builder :
- uncheck the 'Release When Close' in the Behavior group of Window menu of the Panel Attributes, in the inspector window.
it means that i don't want that the panel release itself when it recieving a close message( typically posted when hitting the little red close button on the top left of the panel).
What does it imply? It implies that when the panel is 'closed', its behavior is not anymore : "Free the memory zone it was using";
but now its : "Only hide its view".
It implies too that when the panel is closed, its outlet (translate by the pointer pointing on this object) still pointing on a still used memory zone, and not anymore on a freed memory zony which could contain anything else.
So then let's resume :
- the about panel i 've made only hide itself when the close button is hit.
Next, i did this following step :
- then in the 'File's Owner' identity, just add 'aboutPanel' in the class outlet table view (click plus button); let the type set to id.
I hope that you understood that my intention was to tell my panel that its futur owner (wathever it will be) will have a outlet pointing on itself. In this case, the file's owner is going to be AppController, so i only have to declare the outlet in its header (which is one Aaron Hillegass directive for this challenge).
Now let 's run on paper this little piece of code.
i launch the Raisman app, and my controller class is initialized; during this initialisation, the outlet pointing on my about panel point on nil.
It happens what happens, and i click on "show about panel" in my menu. It calls the showPanel:sender method (if i've correctly linked my Menu Item Target).
Let's see what happens:
First of all i test my AppController outlet aboutPanel :
. It s the first time i launch this method, so my aboutPanel still pointing on nil, which means (!aboutPanel) = YES, so i go to the statement.
In this statement, i load the nib, and i link to it AppController.
BOOL succes = [NSBundle loadNibNamed
"About" owner:self];
If the loading is a succes, my About Panel is unarchived, shown and the file's owner link its outlet aboutPanel to the About Panel. So then the outlet aboutPanel of AppController points now on the About Panel.
If the nib can't be load if print a message of failure in the console.
if (!succes) {
NSLog(@"Failure loading the about panel nib file");
}
That 's what happens when the showAboutPanel:sender is first called.
At this point, now my About Panel is in on front and the outlet aboutPanel points on it and it's not nil.
Then I decide to close the About Panel. After hit the close buton, the panel is no more visible, but it still residing in memory, according the behavior we impose to it. So then my outlet still pointing on a active memory zone well defined.
Further in time, i decide to it again the menu item "Show about Panel"
Let's see what happens in showAboutPanel:sender method:
I test again my outlet ,
but this time aboutPanel is no more nil, it's value is the address of the About Panel(which still existing in memory), so (!aboutPanel) = NO; so then i go to the else statement and i unhide my About Panel, and put it in front :
[aboutPanel makeKeyAndOrderFront:self];
I close again my About Panel, it will not release my Panel, and my outlet will point again on the well defined piece of memory occupied by the About Panel. And So on, And so on.
Let me correct your piece of code, will you.
In your if statement,
if (!aboutPanel)
{
NSLog(@"load then display");
[NSBundle loadNibNamed
"About" owner:self];
[aboutPanel makeKeyAndOrderFront:self];
}
(...)
Calling [aboutPanel makeKeyAndOrderFront:self]; is redundant, because when you load your nib, instances are created and when our about panel is created, its default behavior is to be on front of our app (it's acting like a basic panel).
Anyway, i hardly recommand you to try my piece of code. It works on my mini-mac mac os x 10.5.8.
Your piece of code is valid, but i say that it is not well optimized according me.
Sincerely, me.