Releasing window controllers - at wits end
Releasing window controllers - at wits end
- Subject: Releasing window controllers - at wits end
- From: Ken Tozier <email@hidden>
- Date: Sun, 10 Sep 2006 13:38:45 -0400
Hi all
Sorry to keep posting about this but I am at my wits end. I've read
the documentation here http://developer.apple.com/documentation/Cocoa/
Conceptual/Documents/index.html probably 20 times trying to glean
some new piece of information, but nothing works. When I close a
window, the window controller just keeps chugging along and as more
windows are opened, more controllers are created, it's causing a huge
honking memory leak.
Releasing a window controller seems like an incredibly basic thing
but it's proving to be one of the most difficult problems I've
encountered in my entire project. mean, I've successfully created an
entire page, ad and content management/statistics system, usable in
both a web browser and in Quark, but I can't close a freaking window
controller.
Here's the sequence of steps I want to happen
1. User clicks an entry in a floating palette to execute a command
2. Palette calls plugin to create the corresponding window controller
3. Window controller loads window nib and displays window either as a
modal or non modal
4. User enters data
5. User clicks OK or Cancel
6. Window controller closes window
7. Window controller does some post processing on the user data
8. Window controller posts an "all done" notification
9. Plugin receives notification and releases the window controller
Only problem is that no matter what I do step 9 never happens for
windows I've opened with [[NSApplication sharedApplication]
runModalForWindow: [self window]]. I am adding the correct selector
in the NSNotification->addObserver method but nada.
Could some kind guru take a look at the following and see if they can
spot where I'm screwing up?
Thanks for any help
Ken
Here's my basic window controller create/release methods. This
corresponds with step 2 above
- (void) createDocumentDialogWithWindowNibName:(NSString *) inNibName
{
documentDialog = [[[XTDocumentDialog alloc] initWithPlugin: self
andWindowNibName: inNibName]
autorelease];
[[NSNotificationCenter defaultCenter] addObserver: self
selector:@selector(disposeDialog:)
name: @"PMXDisposeWindowController"
object: nil];
}
- (void) disposeDialog:(NSNotification *) inNotification
{
NSLog(@"about to release dialog = %@", [[inNotification object]
description]);
[[inNotification object] autorelease];
}
Here is my typical modal dialog init method
- (id) initWithPlugin:(XTPlugin *) inPlugin
andWindowNibName:(NSString *) inNibName
{
NSString *path = [inPlugin pathForResource: inNibName ofType: @"nib"];
NSLog(@"nib path = %@", path);
/*
I have no choice but to use NSBundle's initWithWindowNibPath method
rather
than one of he others because my plugin bundle doesn't reside
within the Quark application bundle.
Also I found that the only way I could get a valid window was to
set the owner to self. The file's owner in the nib is set to this
class
and nothing else seemed to work.
I have a suspicion this owner: self thing might be part of the problem
but since, after a week of trying, I couldn't make anything else
work,
I just went with it.
*/
if (self = [super initWithWindowNibPath: path owner: self])
{
plugin = inPlugin;
// init the dialog type flag
[self initDialogType: inNibName];
pages = nil;
selectedPubEditionInfo = nil;
selectedPubDate = nil;
// init the publications array
[self setSites: [plugin siteList]];
[self setSelectedSite: [plugin defaultSite]];
// run panel as a modal dialog
[[NSApplication sharedApplication] runModalForWindow: [self window]];
}
return self;
}
And here's the skeleton of a typical handler bound to the dialog's
"OK" button.
- (void) createWeeklyDocument
{
[[NSApplication sharedApplication] stopModal];
[self close];
/* process user input */
// post the all done notification
[[NSNotificationCenter defaultCenter]
postNotificationName: @"PMXDisposeWindowController"
object: self];
}
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden