Re: When do bound objects get updated?
Re: When do bound objects get updated?
- Subject: Re: When do bound objects get updated?
- From: Glenn Andreas <email@hidden>
- Date: Fri, 16 Jul 2004 11:06:28 -0500
At 8:05 AM -0700 7/16/04, mmalcolm crawford wrote:
On Jul 16, 2004, at 7:30 AM, Glenn Andreas wrote:
Be sure to check the box labeled "Continuously Updates Value" in
the bindings inspector panel for the text field. Without that,
the new value gets sent only when editing is ended by tabbing out
of the field, pressing the return/enter key, or otherwise sending
focus to some other part of the interface like when you click on
the table.
Of course, if you do this, your undo mechanism can get ugly, since
every keystroke then becomes a change.
If you're in this situation, you can typically use something like
textShouldBeginEditing: and textShouldEndEditing: to begin and end
an undo group...
It's trickier than that, because undo-groups are automatically
opened/closed within each cycle of the runloop - and this occurs
across many executions of the run loop. textShouldBeginEditing
impacts the coallescing of undoability of a text field - and you'll
still get the "setFoo:" message each time.
The problem is that because "setFoo:" is called whenever needed (as
defined by the controller) you don't know in this setter why it is
being called (your objects just gets a bunch of "setFoo:"s and then a
bunch of "setBar:"s). And your setter is where you normally
implement the undo mechanism (see the sample code of a setter in
<
http://developer.apple.com/documentation/Cocoa/Conceptual/UndoArchitecture/Tasks/RegisteringUndo.html#//apple_ref/doc/uid/20000206/BABICFDE>).
In a pre-controller architecture, you'd know when, for example, to
best prepare the undo (i.e., the first time you made a change when
that text field was entered), but the whole point of controllers is
to remove all that "frequently coded logic" (FCL?).
One solution is to have the setter, after preparing the undo, disable
the undo manager (disableUndoRegistration) until a different first
responder is chosen, and then re-enable it (enableUndoRegistration).
The undo manager will then have, on its stack, a single action that
sets that ivar to the original value (in the example, back to 200)
and none of the intermediate (1, 10, 102). It gets a bit tricky when
undo/redo is done by the user, but this techinique more or less works.
There are plenty of examples of best ways to write a setter, and
examples (as above) of how to integrate undo into setters, perhaps
there should be a document on how to handle controllers with the
"continously update value" checked and undo in setters...
--
Glenn Andreas email@hidden
mondo blobbo, Cythera, Theldrow, oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.