Re: Binding -- or not -- a button created in code
Re: Binding -- or not -- a button created in code
- Subject: Re: Binding -- or not -- a button created in code
- From: Kyle Sluder <email@hidden>
- Date: Mon, 21 Jun 2010 00:35:36 -0700
On Mon, Jun 21, 2010 at 12:14 AM, Jerry Krinock <email@hidden> wrote:
> In a home-made "collection view", each item contains a checkbox, whose value should represent an attribute in the data model.
So, you are going to have multiple checkbox-style NSButtons
(NSCollectionView approach), not just cell-based drawing
(NSMatrix/NSTableView approach)?
>
> Looking at this from a high level, it seems there are two ways to wire its value
>
> 1. The *modern* way is to -bind::: it to the model when it is created, and -unbind:: it when it is removed from the view permanently. The unbinding can be tricky because "removal" can occur if the item is removed from the collection, or replaced for some reason, or when the window closes. I must be careful to unbind once and only once. I seem to remember that doing this kind of thing in -dealloc is not recommended.
-viewWillMoveToWindow: sounds like it might fit the bill; unbind if
the argument is nil.
>
> 2. If I am *sure* that no other control, code, future feature, plug-in, or script could ever change the model value, I can "simply" wire up its value the *old-fashioned* way, setting it to the current model value upon creation, and wiring its target/action to a method which changes the model. The trick here is if I am really *sure* none of this stuff could ever happen.
Since we don't know your app, there's really no way to comment on
this. It might be valid, it might not.
You might want to give thought to whether it's appropriate to bind
each individual checkbox, or to instead make your "collection view"
the bound object and mediate between the checkboxes and the model.
Checkboxes would call a private action method in your collection view,
which would translate to the appropriate KVC methods on the model.
--Kyle Sluder
>
> Any mistakes or omissions in this?
>
> Jerry Krinock
>
> _______________________________________________
>
> 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
>
_______________________________________________
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