Re: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
Re: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
- Subject: Re: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
- From: "David P. Henderson" <email@hidden>
- Date: Wed, 18 Jul 2001 00:23:56 -0400
>
The only problem is that I did not actually create those objects. I
>
didn't load any nib file at all. I used the default NSApplicationMain()
>
routine that Project Builder puts into the defaul main.m file.
>
But you did create them. You opened the nib file and inserted objects
into it. Additionally, you caused the instance of NSApplication to occur
which loaded the nib. You are responsible.
>
I'm just doing one of the basic tutorials in the Learning Cocoa book
>
which is presumably written for programmers new to Cocoa and mac os x.
>
Unfortunately, from the postings on this list that does not appear to be
the case :(
>
It turns out that the loading of the main nib file probably happens
>
inside NSApplicationMain() (I don't have the source to
>
NSApplicationMain(), but I found the documentation in NSApplication
>
which shows a sample of what that routine may do).
>
It doesn't matter how the nib is loaded. The fact of the matter is that
you inserted object(s) into it. You created the process; you own it; you
have to clean up after it. NSApplication happens to own the nib but you
own the instance of NSApplication.
>
Even if that code sample in the documentation for NSApplicationMain(),
>
it is not immediately apparent HOW I would release objects from the Nib
>
file (ok, windows I can set in IB, got that, thanks); I do not have a
>
reference (variable) to them anywhere that I am aware of. How would I
>
send them the release message? Presumably I can get them somehow, but
>
for a starting Cocoa programmer that may be getting a little advanced
>
don't you think? (If you know the answer on how to dispose of a
>
controller that has been instantiated in the main Nib file, I'd like to
>
know, thanks!).
>
Now, this gets to the crux of the matter. Notification and Delegation
learn them; use them. The problem is that the initial jump into Cocoa is
one of faith, faith that it will all make sense. In this instance, since
NSApplication owns the nib, you can do one of 2 things: either make your
controller object NSApp's delegate, or register your controller object
as an observer of the NSApplicationWillTerminateNotification. Which you
choose, depends on whether or not the user should be able to cancel the
quit. If the user needed be able to stop the terminate, implement
-applicationWillTerminate: either as delegate or notification in your
controller object and send release to self eg:
- (void)applicationWillTerminate:(NSNotification *)notification
{
[self release];
}
Additionally, you could register any object which you instantiate in the
nib as an observer of this notification if you are concerned about
quitting without deallocating. But remember if you need to interfere in
the the quit process set a delegate for NSApp and implement
-applicationShouldTerminate. Only delegates can interfere, not observers.
>
So, I guess that I did create those objects, but for a novice developer
>
it sure seems like they were automagically created by the framework and
>
should be automagically disposed of when the application quits.
>
This is a problem of perception on the part of the novice, not the
framework or nib. Nib files are not magically created. You create them
with Interface Builder. When you save them, IB archives all the objects
in them. When you load them, the objects are unarchived and given to you
to use, replace or dispose. Any technology which is sufficiently removed
from our experience will appear to be magic.
>
So, if this is indeed something that needs to be done, then there is
>
some documentation of this fact that needs to happen. There are two
>
places that come to mind: 1) In the Learning Cocoa book would be a
>
good place to have this since this is many cocoa programmers first
>
learning location; 2) in the documentation for NSApplicationMain where
>
it shows the loading of the nib file.
>
You don't need to know how NSApp...Main works. You do need to understand
the interaction between the objects in your application whether
programmatically created or nib archived.
The resource I found really useful in my learning Cocoa process was a
couple of books buried in the Apple Developer ftp area[1]. Programming
Yellow Box (and Supplemental), but in order to make use of it you need
to be able to deal with the fact that a lot of information about the
tools and framework are out-of-date.
>
In addition, the sample I referenced (Notification sample ch 8) has
>
code in a MyController dealloc method to clean up after itself THAT IS
>
NEVER CALLED as the sample is written (with the current AppKit).
>
See above for how to handle this. But in the examples you cite, the fact
that dealloc isn't called is not a problem. Mach will reap your
application's memory and return it to use for the rest of the system.
>
So, either the sample needs fixing, or the framework does. I'm not
>
currently qualified to put forth an opinion on which needs fixing, I'm
>
just trying to point out that something isn't right here and asking
>
someone who: a) knows more about this framework than I do; and b) has
>
access to the source(s) to change these things, to please fix one or
>
the other.
>
My first conclusion in this situation would be that the example is in
error not the framework. You are critiquing the design of the framework
without understanding how it is designed to function. Granted, good
documentation would remove this problem, but since that doesn't exist,
you'll have to use other resources. Before criticizing the framework as
buggy or errant, stop and ask this list why it works as it does.
>
My only goal is to make a the development experience, software
>
functionality, and user experience as good as possible so that the OS
>
and Developers for it all prosper.
>
It's okay to ask questions. Remember there are no stupid questions, only
stupid answers. But to everyone asking questions, bad attitude will only
get you stupid answers ;)
Dave
[1]
ftp://ftp.apple.com/developer/macosxserver/Training/
--
Chaos Assembly Werks
"Suburbia is where the developer bulldozes out the trees, then names the
streets after them."
- Bill Vaughn