0

A text view should not forward uninvokable commands up the responder chain, the docs say for -[NSTextInputClient doCommandBySelector:]:

If aSelector cannot be invoked, then doCommandBySelector: should not pass this message up the responder chain. NSResponder also implements this method, and it does forward uninvokable commands up the responder chain, but a text view should not. A text view implementing the NSTextInputClient protocol inherits from NSView, which inherits from NSResponder, so your implementation of this method will override the one in NSResponder. It should not call super.

The last sentence does not clarify but only rephrase how things are set up if my text understanding does not fail me.

So there basically just is a prescription: "a text view should not". Period.

But why?

I can fathom a case where you want a text view not react to any/all NSResponder methods but delegate these up to its view controller, for example. Would this cause trouble? Is this just advice to keep text view behavior consistent across macOS apps?

ctietze
  • 2,805
  • 25
  • 46
  • Delegating to a delegate object is not the same as passing up the responder chain. – Willeke Jan 20 '18 at 10:10
  • I still don't get it. `NSTextView` is, by virtue of inheriting from `NSView,` part of the responder chain. The `NSTextInputClient` protocol has the same method requirement as `NSResponder` (`doCommandBySelector:`) but has a much stronger claim. Wouldn't this mean than `NSTextView`s swallow `doCommandBySelector:` calls when they're in the chain? If so, why would that be desirable? – ctietze Jan 22 '18 at 15:26

1 Answers1

1

From The Key-Input Message Sequence:

If the first responder is a text view, the key event enters the text system. The key window sends the text view a keyDown: message with the event as its argument. The keyDown: method passes the event to handleEvent:, which sends the character input to the input context for key binding and interpretation. In response, the input context sends either insertText:replacementRange:, setMarkedText:selectedRange:replacementRange:, or doCommandBySelector: to the text view.

It wouldn't be correct if the text view handles the key event and the scroll view or some other view receives the doCommandBySelector: message. You are not allowed to send doCommandBySelector: to super but you are allowed to send the selector to a delegate.

Willeke
  • 14,578
  • 4
  • 19
  • 47
  • Good find! "It wouldn't be correct" is pretty vague, though. In your scroll view example, I see that this could cause problems when the events are handled by everyone on the view stack. – ctietze Jan 25 '18 at 09:58