Re: NSWindow alloc/dealloc problems
Re: NSWindow alloc/dealloc problems
- Subject: Re: NSWindow alloc/dealloc problems
- From: Alex Reynolds <email@hidden>
- Date: Mon, 29 Nov 2004 12:47:09 -0500
On Nov 29, 2004, at 12:19 PM, j o a r wrote:
-[NSWindow close] and -[NSObject release] are very different methods.
You need to understand what they do, how and why they differ. Neither
of them, on their own, triggers the deallocation of anything. If
you've set the window to be "released on close", calling close will
trigger a release. If a call to release triggers the window to
deallocate, the window will in turn release it's view hierarchy, most
often triggering it to be deallocated in turn.
I think I do understand the difference, at least so far as what is
explained in Apple's online documentation.
Close does trigger a release (because I told it to in
setReleasedWhenClosed) which in turn should dealloc the NSWindow
instance.
Here is the entire method I use that handles alternate presses of the
"capture" button.
I'm not quite sure that I understand why you assign the content view
to the window like that.
How else do I assign a content view to a window? I'm only reading
Apple's documentation, now.
Is there another method I should call instead, to do this?
It does, in any case, seem to be the root of the problem - as you
appear to only create the content view once. If you want to re-use it
between your calls to this method, you need to add a reference to it
and retain it, so that you can hold on to it when it's enclosing
window is deallocated (but why deallocate the window if you plan to
open it again?).
If I change the target display (in a multiple monitor setup) or change
the target display mode (resolution of a selected monitor), the content
view doesn't change (and shouldn't need releasing) but the NSWindow
object instance does need to be remade, depending on the state of the
application when the capture button is pressed.
I appreciate your patient and polite help.
Regards,
Alex
_______________________________________________
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