Re: Opposite of windowDidLoad
Re: Opposite of windowDidLoad
- Subject: Re: Opposite of windowDidLoad
- From: Quincey Morris <email@hidden>
- Date: Thu, 12 Jan 2017 10:53:51 -0800
- Feedback-id: 167118m:167118agrif8a:167118smY4abFL0a:SMTPCORP
On Jan 12, 2017, at 03:46 , Daryle Walker <email@hidden> wrote:
>
> I was thinking of adding a Cocoa Binding during my window-controller's did-load method. But where would the unbinding go?
You’re sort of asking the wrong question. The time to bind or unbind is dependent on the thing being bound and the thing being bound to. You must establish the binding after both things have been created, and tear down the binding before either thing is destroyed.
Note that windowDidLoad is a place where things like this are often done, because it happens at a time where you know that everything in the window that comes from a NIB file has been loaded and therefore exists.
> I see waiting until deinit or implementing NSWindowDelegate and using windowWillClose.
Quibble: you *conform to* NSWindowDelegate (all of its methods are optional, so you can conform to it without implementing anything in it), and you *implement* windowWillClose (or not, since it is optional).
windowWillClose is an acceptable place to tear down the binding only if (a) the thing bound, and the thing bound to, still exist, and (b) there is no chance that the window will be re-opened. Both of those are typically true, but it does depend on what you’re doing.
Window dealloc/deinit is also a possible time, but again you need to be sure that the relevant objects still exist, probably by keeping strong references to them in the window controller itself (and again it depends on what you’re doing).
> Is there a similar access point for view-controllers?
Not for tearing down the binding. viewDidLoad is provided for you at the completion of NIB loading, for the same reason as windowDidLoad: because it’s hard otherwise for your code to know when NIB loading is complete without being told. For the opposite action, you can do it at dealloc/deinit as above.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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