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 protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
