• 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: Swift 3 macOS read keyboard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Swift 3 macOS read keyboard


  • Subject: Re: Swift 3 macOS read keyboard
  • From: Quincey Morris <email@hidden>
  • Date: Mon, 10 Oct 2016 15:36:00 -0700
  • Feedback-id: 167118m:167118agrif8a:167118sLqS2pywu1:SMTPCORP

On Oct 10, 2016, at 15:07 , Graham Cox <email@hidden> wrote:
>
> NSWindow, NSWindowController and NSView, NSViewController all inherit from NSResponder, which provide standard methods for dealing with keyUp and keyDown events.

I agree with everything you said, but a bit of caution is needed with NSViewController subclasses, if the deployment target is earlier than 10.10.

Previously, view controllers were not in the responder chain (unless you wrote code to put them there), and the “responder chain for events” section of the Event Handling Guide doesn’t mention view controllers as any kind of special case, as it does for window controllers.

I believe there are 4 possibilities:

1. Subclass NSView to return true from ‘acceptsFirstResponder’. Otherwise the events will go to the window.

2. Subclass NSViewController to handle keyUp/Down. But it’s also necessary to do #1, and if you want pre-10.10 compatibility, you should override keyUp/Down in the view subclass instead.

3. Subclass NSWindow to handle keyUp/Down.

4. Subclass NSWindowController to handle keyUp/Down.

Of these, #4 is the easiest and least treacherous, but I get the impression Eric wants to centralize his business logic in the view controller and pretty much ignore the window controller (which is a fairly reasonable attitude in these storyboard days). In that case, he can have the window controller call view controller methods, preferably *not* keyUp/Down overrides, but it would make more sense to encapsulate everything in the view/view controller combination, which means #1 and probably #2, depending on deployment.

What I find interesting about this problem is that there’s a really easy solution, except that it’s easy only in the it’s-a-very-*small*-can-of-worms sense. That’s why we love old-school Cocoa.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Swift 3 macOS read keyboard
      • From: Doug Hill <email@hidden>
    • Re: Swift 3 macOS read keyboard
      • From: Eric Dolecki <email@hidden>
References: 
 >Swift 3 macOS read keyboard (From: "Eric E. Dolecki" <email@hidden>)
 >Re: Swift 3 macOS read keyboard (From: "Eric E. Dolecki" <email@hidden>)
 >Re: Swift 3 macOS read keyboard (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Swift 3 macOS read keyboard
  • Next by Date: Re: Swift 3 macOS read keyboard
  • Previous by thread: Re: Swift 3 macOS read keyboard
  • Next by thread: Re: Swift 3 macOS read keyboard
  • Index(es):
    • Date
    • Thread