• 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: making NSView firstResponder/key
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: making NSView firstResponder/key


  • Subject: Re: making NSView firstResponder/key
  • From: Ken Thomases <email@hidden>
  • Date: Sat, 17 May 2014 04:33:24 -0500

On May 17, 2014, at 4:01 AM, Roland King wrote:

> Looked at the field editor docs but it didn't instantly make sense.

Text fields use a secondary view to actually handle the editing.  The text field objects themselves, as views, only really perform display when they don't have focus.  When they do, there's another view sitting in front of them that handles both the display and the input handling.  That other view is the field editor and it's the actual first responder.

> Which overrides were supposed to call through to super? Obviously not  canBecomeFirstResponder etc as that's the behaviour I was trying to change. Do you mean becomeFirstResponder and resignFirstResponder? Those were just logging methods but indeed they didn't call through.

Right.  Methods which just return information about the object's behavior need not call through because you're changing the behavior (although if you're subclassing NSTextField, the superclass implementations should presumably already do the right thing).  But methods which are informing the object about state changes, those have to make it through to the superclass if you want it to behave sensibly.

> I went another way with this for this project and just quickly wrote my own NSView subclass which draws its own content, as the content here is trivially simple (it's one digit). That works perfectly and all the responder and key methods do exactly what I expected (all I did was change the base class to start with and they instantly began to work). So clearly I was breaking the NSTextField assumptions by overriding bits of it. I'll keep going the way I'm going with this one but I'd like to understand where I went wrong.

Be careful.  You may want to test if your custom view does the right thing with input methods (e.g. Kotoeri/Hiragana or Pinyin).  Also with VoiceOver.  If a custom view is an alternative kind of text view, it should adopt NSTextInputClient and implement its methods.

Regards,
Ken


_______________________________________________

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: making NSView firstResponder/key
      • From: Roland King <email@hidden>
References: 
 >making NSView firstResponder/key (From: Roland King <email@hidden>)
 >Re: making NSView firstResponder/key (From: Ken Thomases <email@hidden>)
 >Re: making NSView firstResponder/key (From: Roland King <email@hidden>)

  • Prev by Date: Re: making NSView firstResponder/key
  • Next by Date: Re: making NSView firstResponder/key
  • Previous by thread: Re: making NSView firstResponder/key
  • Next by thread: Re: making NSView firstResponder/key
  • Index(es):
    • Date
    • Thread