Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: When do bound objects get updated?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When do bound objects get updated?

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.

References: 
 >When do bound objects get updated? (From: Darren Ford <email@hidden>)
 >Re: When do bound objects get updated? (From: Larry Fransson <email@hidden>)
 >Re: When do bound objects get updated? (From: Glenn Andreas <email@hidden>)
 >Re: When do bound objects get updated? (From: mmalcolm crawford <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.