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 balan
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
> 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 Owne
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.
>>
>
>> R
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 original
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 ultimate
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 thin
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 ref
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 "De
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 contr
On Fri, Sep 26, 2008 at 2:45 PM, Daniel Child <[EMAIL PROTECTED]> wrote:
> I should? Then how do I get the reference back? If windowA is a window
> outlet in my AppController, then first time around I don't do anything. It
> is automatically assigned a reference when the window loads, and I can use
--- On Fri, 9/26/08, Daniel Child <[EMAIL PROTECTED]> wrote:
> I should? Then how do I get the reference back? If windowA
> is a window
> outlet in my AppController, then first time around I
> don't do
> anything.
If it's accessed via an outlet in your app controller, you probably don't have
Sep 2008 10:34:50 -0500
From: Scott Ribe <[EMAIL PROTECTED]>
Subject: Re: showing window causes EXC_BAD_ACCESS
To: Michael Ash <[EMAIL PROTECTED]>, Cocoa Developers
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="US-ASCII"
I can
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 th
> 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 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 knowin
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_ACC
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 secon
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 exi
19 matches
Mail list logo
