Coalescing undos because of bindings
Coalescing undos because of bindings
- Subject: Coalescing undos because of bindings
- From: Glenn Andreas <email@hidden>
- Date: Fri, 18 Jun 2004 10:57:55 -0500
I've got a text field bound to a (float) variable, and I use binding
to automate that connection. I've got the binding set to send
continuous updates so that as I type in a value, a preview automatic
updates with the current value.
However, I also use an undo manager with that variable. The setter looks like:
-(void) setLength: (float) length
{
if (length != myLength) {
[[myUndoManager prepareWithInvocationTarget: self]
setLength: myLength];
myLength = length;
}
}
The problem is that when you type in a value like "1234" into the
field, this results in 4 undo actions (original value->1, 1->12,
12->123, 123->1234) where I really only want one (original
value->1234). If I turn off the continuous update flag in the
binding, this will result in only the single action, but then my
preview update only happens when you leave the field (which isn't
what I want).
In general, to coalesce undo's one would use notifications (which can
be coalesced), except that this technique works for things like
sliders (or other things that are tracked in a "mouse down" loop),
and not text input.
If the "last" undoable action was "setLength" I'd basically like to
skip the adding a new undo action (since the original action would
be an invocation of [self setLength: originalValue]), but there
doesn't seem to be a way to query what the invocation was. I suppose
I could also group the undo actions, perhaps based on when the first
responder becomes/stops being the field, but I'm not sure if that
would catch everything correctly (since you could type an undo while
the group is still open - i.e., the focus is still on the field, and
then when you exit the field closing the group won't have the open
group be there anymore).
Suggestions?
And doesn't it seem like binding should be able to manage undo's
(assuming there was a way to tell it about the undo manager)? After
all, they automatically call [boundObject setFoo: newValue], so they
shouldn't be able to do something like [[[boundObject undoManager]
prepareWithInvocationTarget: boundObject] setFoo: [boundObject foo]]
for free as well?
--
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.