Re: Synchronized outlets and actions
Re: Synchronized outlets and actions
- Subject: Re: Synchronized outlets and actions
- From: Jonathon Mah <email@hidden>
- Date: Wed, 4 Jan 2006 23:17:44 +1030
Hi Dan,
On 2006-01-04, at 09:36, Dan Price wrote:
My app has properties which can be set by either a
text field, or a slider. If the user enters a value in
the field, the property needs to be updated and the
slider value must be changed to reflect the new value.
Likewise, if the slider is dragged, the property must
be updated and the text field changed to show the new
setting. This sounds easy, but it seems that controls
in IB can only have a single action connection. The
slider can update the field, or the property, but not
both. They need to be synchronized together, while
avoiding a problematic circular-reference.
Is there a simple way to do this? My app has dozens of
controls split across several utility panels.
Or am I missing the point?
You're missing the point. (Admittedly, it is rather subtle to begin
with.) If I understand you correctly, your thinking is similar to
this: { The user types something in the text field. The text field
then sends a message to update the model and then another message to
update the slider. } The problem with this is that then each control
needs to know about every other control representing the same value,
and you have to consider circular references (as you said).
The traditional Cocoa way of handling this situation is thus: { The
user types something into the text field. The text field updates the
model. The controller notices the update, and updates the other
controls (i.e. the slider). } In the past (pre-10.3) the whole
"noticing the update" stuff was handled by having the model post a
notification that its value updated. The controller, which had
previously subscribed itself to its model's notifications, would
receive a callback and update the relevant controls. So it's very
similar to the first situation, except the update code has been moved
from the view (button, slider) to the controller.
This is where Cocoa Bindings comes in. With bindings, all the
notification and update stuff is handled for you. When you say "bind
the value of this text field to the age of this person object", the
controller will observe both the model object (person) and the view
object (text field), and keep them in sync. When the text field
changes, the controller will update the model. When the model
changes, the controller will update the text field and slider.
So, bindings are what you want. When I first tried it out, I was
confused as hell. (And, it seems, so were many many others.) But
after a short time it will just "click", and you'll wonder how you
ever lived without them. One fallacy common to binding newbies: You
_do not_ bind, say, the text field to both the model and the slider.
Rather, you bind both the text field and the slider to the model
object -- the text field shouldn't and doesn't need to know that
there's a slider representing the same value, and vice-versa.
I think I've rambled on enough. Sorry about that.
Jonathon Mah
email@hidden
_______________________________________________
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