NSTableView and Releasing window controllers
NSTableView and Releasing window controllers
- Subject: NSTableView and Releasing window controllers
- From: Boyd Collier <email@hidden>
- Date: Mon, 12 Feb 2007 23:02:33 -0800
I've been trying to get a table created from a nib to work correctly
when it is "re-used" to display data from a source having different
number of rows. I've tried two approaches, but each has a problem. If
I use a single window controller that is the file's owner in the nib
that contains the table view, it works fine for the first set of
records I want to display. But if the window is then closed and
subsequently I use the same window controller to show a table with a
different number of rows, I get one of two incorrect results. If the
first table showed (for example) 2 rows and the second table attempts
to show 4 rows, only the first 2 are shown. Or, if the first table
shows 4 rows and then I close the window containing it and open a
window (controlled by the same window controller) and attempt to show
2 rows, the application quits when my objectValueForTableColumn
method is called more often than twice, and this is the case even
though the number of records in my data source is two and this is
confirmed by the method numberOfRowsInTableView. On the other hand,
if I create a new window controller each time I want to open a window
with a table, then the right number of rows is shown, which makes
sense. However, closing the window doesn't release the window
controller, which appears to create a memory leak, as noted by Ken
Tozier (see below). I've tried everything I can think of (e.g.
reloadData) but to no avail. Is the only solution using separate
controllers for each table, or am I overlooking something (which
seems likely)?
Boyd
On Sep 10, 2006, at 3:18 PM, Ken Tozier wrote:
Hmmm. It does seem to imply that, but it's directly contradicted by
this paragraph from my link below
"If you want closing a window to deallocate the window and its
window controller when it isn’t owned by a document, you should add
code to the object that does own the window controller to observe
the NSWindow notification NSWindowWillCloseNotification or, as
window delegate, implement the windowWillClose: method. When you
see that your window controller’s window is closing, you can
autorelease the window controller, which will also have the effect
of releasing the window and any other top-level objects loaded from
the window controller’s nib file when the application reenters the
main event loop."
There is also the little matter that if window controllers can't be
released then every Cocoa Application contains a major memory leak
if they use dialogs. That seems unlikely so I must be doing
something wrong.
On Sep 10, 2006, at 2:53 PM, Byron Wright wrote:
If you are loading the nib file every time then that is your
problem. NSBundles cannot be unloaded from memory according to
this document : https://developer.apple.com/documentation/Cocoa/
Conceptual/LoadingCode/Concepts/CFNSBundle.html
On Sep 10, 2006, at 10:38 AM, Ken Tozier wrote:
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden