• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Undo Mysteries
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undo Mysteries


  • Subject: Re: Undo Mysteries
  • From: James DiPalma <email@hidden>
  • Date: Tue, 15 Jun 2004 18:38:43 -0700

On Jun 15, 2004, at 2:45 PM, Tim Hart wrote:
Not enough information here to completely answer your question.

His only question was

On Tuesday, June 15, 2004, at 02:48PM, Gerriet M. Denkmann <email@hidden> wrote:
The Undo menu item sends undo: to the first responder. [...]
So: who is really responding to this message?

Which is simple to answer because Gerriet asked his NSApplication instance who is really responding to this message:

The Undo menu item sends undo: to the first responder.
[ NSApp targetForAction: @selector(undo:) ] returns NSWIndow.

NSApplication's targetForAction would not return an NSWindow instance here if that instance did not respond to undo:.

NSWindow will forward messages it can't handle to it's delegate. If you've registered a delegate to your NSWindow, that could be one possibility.

If a window's delegate would be a target for an action, it would get returned by targetForAction: (i.e. an NSWindow instance would not get returned if its delegate was actually this action's target). In Gerriet's case, NSWindow responds, so its delegate never gets asked if it could be a target for undo: actions (if someone wants their delegate to handle undo:, use a subclass and return NO during respondsToSelector: -- not recommended unless you have a really good reason).

But NSWIndow does not have a undo: method in its header file.

Well, that is confusing isn't it. Its not documented, its not in a header, but its there handling undo:.

Everything works, but I do not understand why.

It just works; why should we need to know how it works (:

Text fields also have their own undo manager, and may be involved in handling the message.

I don't think NSTextFields have an undo manager ivar; all NSResponders have an -undoManager instance method, but by default it "simply passes this message to the next responder." which probably leads to a window that will create an NSUndoManager.

NSTextViews (which is what you meant?) does override NSResponder's -undoManager, but there is no indication what it is doing. Some simple testing with gdb might shed some light, but if I where forced to guess, I would say it is simply caching its window's undoManager return value (but, I wouldn't give myself good odds on being right).

NSTextView does not respond to undo:, so these instances are not involved in handling an undo: action.


-jim

P.S. Please be careful when reading cocoa-dev, some of us who answer don't know everything we think we know. I've been wrong many times before (although, I don't think I'm wrong here -- at least, I hope not; that would be embarrassing :).
_______________________________________________
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: 
 >Re: Undo Mysteries (From: Tim Hart <email@hidden>)

  • Prev by Date: Re: option-click hides apps
  • Next by Date: Disappearing programmatic NSTextView in tab when setting autoresizingmask
  • Previous by thread: Re: Undo Mysteries
  • Next by thread: WebKit And Threading
  • Index(es):
    • Date
    • Thread