Am Sa,27.09.2008 um 22:44 schrieb Uli Kusterer:
On 27.09.2008, at 22:13, Michael Ash wrote:
But suddenly you're back to having to think about the global picture
of who owns objects, which is what Cocoa's memory management system
is
supposed to avoid.
Retains and releases should be
Except that in every case I've seen of people getting bit by this, the
window was still being implicitly retained by the nib's File's Owner.
You should definitely *not* expect a top-level nib object to go away
until File's Owner releases it.
Sure. The design intent here is that File's Owner
On Sun, Sep 28, 2008 at 11:01 AM, Scott Ribe [EMAIL PROTECTED] wrote:
Except that in every case I've seen of people getting bit by this, the
window was still being implicitly retained by the nib's File's Owner.
You should definitely *not* expect a top-level nib object to go away
until File's
No. But I'm still wondering. How would you set up a reference again if
you chose to have the window released on close...without reloading the
entire nib, which is probably counterproductive.
On Sep 26, 2008, at 3:30 PM, Charles Steinman wrote:
If it's accessed via an outlet in your app
On Sat, Sep 27, 2008 at 1:06 PM, Daniel Child [EMAIL PROTECTED] wrote:
No. But I'm still wondering. How would you set up a reference again if you
chose to have the window released on close...without reloading the entire
nib, which is probably counterproductive.
Released does not mean
On 27.09.2008, at 19:06, Daniel Child wrote:
No. But I'm still wondering. How would you set up a reference again
if you chose to have the window released on close...without
reloading the entire nib, which is probably counterproductive.
Well, for some windows, you might not need another
On Sat, Sep 27, 2008 at 2:39 PM, Uli Kusterer
[EMAIL PROTECTED] wrote:
Also, there are cases where someone else is going to retain a window
anyway. Closing a window will simply call -release, if someone else retained
it, the object won't go away.
But suddenly you're back to having to think
On 27.09.2008, at 22:13, Michael Ash wrote:
But suddenly you're back to having to think about the global picture
of who owns objects, which is what Cocoa's memory management system is
supposed to avoid.
Retains and releases should be balanced. This doesn't just means that
they should
On Sep 27, 2008, at 4:44 PM, Uli Kusterer wrote:
That said, I fully agree on one partial point you raised: 'Release
when closed' is dangerous and complicates matters. It should be off
by default, and it's very likely that nobody would miss it. That
said, I don't know what it was
On Sat, Sep 27, 2008 at 4:44 PM, Uli Kusterer
[EMAIL PROTECTED] wrote:
On 27.09.2008, at 22:13, Michael Ash wrote:
But suddenly you're back to having to think about the global picture
of who owns objects, which is what Cocoa's memory management system is
supposed to avoid.
Retains and
I can't think of a single reasonable use case for it
An app with many windows, many of which can display multiple instances at a
time--they should be released when closed.
I'd turn the question around--why do people assume that a single instance of
a window can be closed and then re-displayed,
On Fri, Sep 26, 2008 at 11:34 AM, Scott Ribe [EMAIL PROTECTED] wrote:
I can't think of a single reasonable use case for it
An app with many windows, many of which can display multiple instances at a
time--they should be released when closed.
Sure. By the objects that own them. Them's the
:50 -0500
From: Scott Ribe [EMAIL PROTECTED]
Subject: Re: showing window causes EXC_BAD_ACCESS
To: Michael Ash [EMAIL PROTECTED], Cocoa Developers
cocoa-dev@lists.apple.com
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII
I can't think of a single
Hi,
I'm stumped. I have a button in a master window tied to a method that
simply shows another window. The method is as simple as they come.
- (IBAction) showMLTableListings: (id) sender
{
[mLTableListingsWindow makeKeyAndOrderFront: self];
}
where mLTableListingsWindow is simply
On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED] wrote:
If I press the button in question once, the window dutifully comes up. If I
close the window and press the button a second time, I get EXC_BAD_ACCESS.
Debugging, I found that both self and mLTableListingsWindow still exist.
THANK YOU! That solved it for all of the windows.
On Sep 25, 2008, at 4:25 PM, Kyle Sluder wrote:
On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED]
wrote:
If I press the button in question once, the window dutifully comes
up. If I
close the window and press the button a second
On Thu, Sep 25, 2008 at 4:25 PM, Kyle Sluder
[EMAIL PROTECTED] wrote:
On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED] wrote:
If I press the button in question once, the window dutifully comes up. If I
close the window and press the button a second time, I get EXC_BAD_ACCESS.
On Fri, Sep 26, 2008 at 12:07 AM, Michael Ash [EMAIL PROTECTED] wrote:
Wandering slightly, but this makes me wonder, why does this flag
exist? I can't think of a single reasonable use case for it, and it
seems to cause no end to trouble to people who have somehow enabled it
without knowing it.
18 matches
Mail list logo
