Re: Undo logic location?
Re: Undo logic location?
- Subject: Re: Undo logic location?
- From: glenn andreas <email@hidden>
- Date: Thu, 6 Jan 2005 10:07:52 -0600
On Jan 6, 2005, at 8:12 AM, Jim Correia wrote:
On Jan 6, 2005, at 1:51 AM, Tom Davies wrote:
and I set the owner of the Catalogue to the MyDocument instance, but
I'd rather not have undo logic in my model at all.
1. Where does the undo logic belong?
That's a good question.
Does anyone have experience with using this in a real world sized
system? Which approach worked better (or not) and why?
Thanks,
Jim
One anecdotal comment (and I'll leave it up to the reader to determine
how this impacts "which is better").
I've got an application with a text field where you type a number in
(the margin on a page). There is a view which updates it's display
based on that number (a preview of the page with the margin values),
and I've got the bindings set up to validate immediately, so as you
type in the number 1.234, the view first displays the value based on 1,
then 1.2, then 1.23, then 1.234.
The model kept track of undoing (it had an undo manager associated with
it, and used standard undo mechanisms in the setter).
Everything works great, until they go to undo. Suppose that the margin
value was 0.5 and then they typed in 1.234. So at this point they hit
"undo" and expect the result to return to 0.5. Unfortunately, because
the setter had been called for each successive value (which is how the
model gets updated so that the preview view can display correctly),
each one of those intermediate keystrokes were recorded as separate
actions, so instead of showing 0.5, it shows 1.23, and then 1.2, and
then 1. and then 1, and then finally reverts back to 0.5
The workaround was to, in the setter, when getting the undo manager for
the model, use the name of the instance variable to determine if we
really wanted the "real" undo manager (or to return NULL which would
cause the action to be ignored). The result was that when the value
was 0.5 and we typed a "1" which caused the setter to be called with a
value of 1, we got the undo manager "for margin", and since the last
time we got the undo manager it was something else, we use the real
undo manager (which recorded an undo action of "set to 0.5"). The next
keystroke "." again calls the setter, and the undo manager "for margin"
is obtained, but since it was for the same instance variable, that
routine would return NULL, so that undo action was ignored.
It works pretty good, though if you do a bunch of changes on the same
field, intermediate ones were skipped (start at 0.5, type in 1.234, and
then reselect and change it to 0.75 instead, doing an undo went back to
0.5 instead of 1.234). That's probably not too bad of behavior, though
there's some funkyness due to the fact that there are a couple of other
ways to change that margin value beside entering it in the field (such
as hitting the "use printer margin" button) which sometimes interacted
in strange ways.
Glenn Andreas email@hidden
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
_______________________________________________
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