Thanks Quincey, that makes sense what you're saying about it being more an action method, and your suggested approach sounds nice.
However, I have not managed to quite get things working based on what I think you were describing. I have set up an action on the checkbox, and based on your comment about "With no setter, the binding won’t try to update the property, it’ll basically be read-only" I changed the bound property to read-only. Maybe that was not what you had intended, but with Xcode 5 at least there did not seem to be a way I could explicitly say that the binding should only be used for reading only. Anyway, if I do that, I get an error: "this class is not key value coding-compliant for the key globalChannelEnableState". I wonder if I have misunderstood what you were meaning? Also, when you write: > You don’t need to dispatch anything to a later iteration of the main event > loop. (Even in your current code — the setter will automatically generate the > KVO notification, so doing it again later is redundant.) which of the three choices of code (switched by #if statements...) are you referring to, from the code I originally posted? For me, in the first and third options the will/didChangeValue calls are essential to avoid the checkbox being left displaying '-' state. Is that not the behaviour you would expect here? One option would be to take up your suggestion of the action method, but abandon the binding altogether and just set the actual state of the UI element directly from my code. I'd definitely be interested in understanding what it sounded like you were suggesting with a "basically read-only" binding though... Cheers Jonny On 8 Jul 2016, at 18:35, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > On Jul 8, 2016, at 05:36 , Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> > wrote: >> >> My setter code currently looks like this: >> >> -(void)setGlobalChannelEnableState:(NSInteger)state > > In the circumstances you describe, a setter method is effectively an action > method, not a setter — that is, it becomes a method that’s called when your > code needs to do something, rather than a way to set some state. As you’ve > found, the real setter method tends to work against you here, because you > have to figure out what the binding expects with the changed value it thinks > it’s setting. > > So, I think a cleaner approach is to leave out the setter method entirely, > and use a real action method instead. With no setter, the binding won’t try > to update the property, it’ll basically be read-only. When the checkbox is > clicked, the action method is still invoked — it’s a NSButton, after all. All > the action method has to do is retrieve the current global state via the > getter, then set the individual states needed to flip it, sandwiched between > one pair of will/didChange calls for the key “globalChannelEnableState”. > > You don’t need to dispatch anything to a later iteration of the main event > loop. (Even in your current code — the setter will automatically generate the > KVO notification, so doing it again later is redundant.) > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
