Re: How to validate the Undo menu item?
Re: How to validate the Undo menu item?
- Subject: Re: How to validate the Undo menu item?
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 24 Apr 2002 13:21:39 -0400
on 02-04-24 10:35 AM, Brian Webster at email@hidden wrote:
>
But if they're modifying the same data, it doesn't really make
>
sense to have to rewrite the undo code and validation for each
>
view that could be the first responder. There may be some
>
differences in the validation depending on which view is first
>
responder, but the window controller or document would be
>
perfectly capable of managing this distinction.
>
>
So, I'm not really sure what the "right" answer is. I've always
>
implemented my undo validation in my document just because it
>
seemed the natural place to do it, since the document is the
>
object that creates and holds the undo manager, and it's right
>
there in the responder chain all the time, ready to validate.
I understand what you're saying, but I tend to come at this sort of question
from a different angle.
In my view, customized behavior should almost always be pushed down the
object hierarchy as far as possible, where it can be encapsulated and
isolated from larger document-wide or application-wide behaviors. I think of
this as basic object-oriented design theory and practice. It certainly has
payoffs: it's easier to write this routine, because I don't have to test
whether the desired object is first responder; for that reason, it
presumably executes more efficiently (relying on Cocoa's object resolution
mechanisms instead of my own if tests); and if I decide to remove the table
view from my application, I won't have to go into my document class and
expunge undo code specific to the table view. I'm much more comfortable that
I'm on the right track when things in my application like undo management
are decentralized to their appropriate objects, rather than hooked up in a
string of if clauses or a case statement. (Of course, reasonable compromise
is required in the interest of practicality; I'm not a purist about this, by
any means. For example, a lot of text processing and user data entry
validation is handled by delegate methods centralized in my window
controller, and each of them typically ends up full of if clauses testing
which user control generated the message. If I remove one of these user
controls from my application, I will have to modify the window controller,
too. However, I expect this more of a window controller than of a document.)
In this case, I only want to alter the standard, built-in undo menu item
behavior when this table view is first responder, so my first instinct is to
put the undo menu item validation in the table view object. I suppose I
could instead put it in the corresponding model object (the table view's
datasource, say). But the fact that validation depends on the state of the
table view reinforces my first instinct.
The table view, like all the other views, are "right there in the responder
chain," so the fact that the document is also accessible in that way doesn't
differentiate it from the views.
The bottom line, for me, is that the undo manager partakes of both the view
and the model. It relates to the view because its function is made visible
and is manipulated in the undo and redo menu items and it often generates
changes in view objects, and it relates to the model because it alters the
state of the data. I guess I would say it is more like a controller.
In my increasingly complex document-based application, my subclass of
NSDocument is very, very small. There are only a few document-wide behaviors
encapsulated in it, mostly relating to its persistent data storage function.
Most other document-related behaviors are pushed down into lower-level model
objects, one for each group of conceptually related data structures. My
document object is really just a controller of the several model objects.
My document happens to "own" the application's undo manager, but that is
mostly because my application supports multiple documents as well as
multiple windows to access any one document. It makes object-oriented sense
to encapsulate the undo behavior as much as possible in each document rather
than in each window controller. But this doesn't seem to me to impose any
necessary constraint on pushing specific undo behaviors into more
specialized objects.
>
>
> When I say it doesn't work, I mean that, although the validateMenuItem;
>
> method gets called in my document for other menu items, it
>
> never gets called
>
> for the Undo menu item. For that, I would have to implement undo: in my
>
> document, and then I still would have the problem of not
>
> knowing what to do
>
> in undo:.
>
>
That's simple:
>
>
-(void)undo:(id)sender
>
{
>
[[self undoManager] undo];
>
}
This doesn't work. I can't figure out why.
Or maybe it works, but something else is getting in the way of my testing
it. That's the problem I'm really interested in solving. It's been keeping
me awake nights. Once I put the undo: method in my table view subclass to
force menu validation there, my special undo menu items lose their custom
names and apparently also their association with specific undo actions. The
undo menu items are suddenly all just "Undo," instead of "Undo Edit" or
"Undo Add Record." This is probably just a bug somewhere in my code (or my
brain), but I'm having a very hard time finding it.
>
Also, checking whether the undo manager canUndo or canRedo is a
>
good thing to put into validation for these items, since they
>
shouldn't be enabled if the undo/redo stack is empty. I think
>
NSResponder's auto-handling of undo: and its validation does
>
this, but if you want custom validation, you'll have to add it
>
yourself to whatever other code you write.
Yes, but it hasn't helped me.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.