• 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: NSTextField eating Escape [Solved]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTextField eating Escape [Solved]


  • Subject: Re: NSTextField eating Escape [Solved]
  • From: Ricky Sharp <email@hidden>
  • Date: Sat, 1 Oct 2005 19:59:07 -0500


On Sep 30, 2005, at 7:40 PM, Douglas Davidson wrote:


On Sep 30, 2005, at 4:48 PM, Ricky Sharp wrote:

To process key events, I've implemented keyDown: in IIContentWindow. This simply dispatches the event. One of my handlers knows how to deal with Escape and Return/Enter (to simulate clicks on Cancel and Default buttons). In the above hierarchy, IIBackground and IIGraphic cannot become key, and cannot be made the first responder. My button classes are just the opposite.

Now then, whenever the text field has the keyboard focus, Escape does nothing. I've set breakpoints in my window's keyDown:, but that is never hit. It was only reached by some keys (e.g. many of the function keys). Escape, along with many navigational keys such as Home and End did nothing. And, as expected, you could enter text a-ok into the field with all the other keys or input methods.

Since the text field's parent was an IIGraphic, I implemented keyDown: in there; thinking that the key event would be propagated to its parent. It too was never reached when I hit Escape. I tried allowing IIGraphic to become key and become the first responder, but that didn't change the outcome.


The window receives events from NSApp via sendEvent:; it then passes them on to the first responder via the appropriate method, in this case keyDown:. If the first responder doesn't handle the event, it will usually pass it on.


However, when a text field is editing, the first responder will be the field editor, which will usually want all key events--field editors are designed to handle typing, after all. As a special exception, the escape key may be handled differently, but only if it is used as a key equivalent by some menu item, or if there is something to handle cancel:, such as a Cancel button. Otherwise the field editor wants it.

If you don't fit into one of the exceptional cases, and you need to deal with a key before the field editor gets it, you will need to do so in your window's sendEvent: method, or in NSApp's sendEvent:.

Thank you for this excellent description, Douglas. All I had to do was to implement cancelOperation: in my NSWindow subclass; allowing me to take advantage of one of the special exceptions. I then removed the Escape key logic from my keyDown: implementation.


Another good thing about this solution was that I gained support for handling Command-period.

___________________________________________________________
Ricky A. Sharp         mailto:email@hidden
Instant Interactive(tm)   http://www.instantinteractive.com

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Selector 'release' sent to dealloced instance of class NSDeviceRGBColor ??
  • Next by Date: Re: Reading all data before the NSTask terminates,
  • Previous by thread: Re: Reading all data before the NSTask terminates,
  • Next by thread: Too many @selector statements?
  • Index(es):
    • Date
    • Thread