Re: Key Equivalents (and now TextField Delegate Problems)
Re: Key Equivalents (and now TextField Delegate Problems)
- Subject: Re: Key Equivalents (and now TextField Delegate Problems)
- From: email@hidden
- Date: Thu, 16 May 2002 10:29:55 -0700
John Nairn wrote:
|Thanks for the input, but I still can not get key equivalents to work.
|Here are some details:
|
|1. The interface has a TextField, 3 buttons, and a TextView. The focus
|is on the TextField.
|
|2. All buttons are connected to actions and all actions work correctly
|when the button is clicked
|
|3. One, for example, has key equivalent Y, pop up at <no key> and
|command key check box checked
|
|4. When running, the command keys are ignored. I set breakpoint in
|action routines to verify they never get called
|
|Is the TextField (or TextView) interfering with the key events? Perhaps
|key equivalents only work when there are only buttons? Or do I need more
|to get them working?
I put together an ultra-simple app that had exactly what you described, and nothing more, and rigged it to show me what was going on as key equivalents were pressed. (I did this by defining performKeyEquivalent: methods for app-specific subclasses of NSWindow, NSButton, NSTextView, and NSTextField, making each the custom subclass of the corresponding UI element.) After some experimentation, I think I've found what's screwing you up: the key equivalent field in IB is case-sensitive. If you enter "Y", you have to press command-*shift*-Y to invoke the action. Without the shift key, nothing happens. If, however, you enter (lowercase) "y", command-y does what you expect, text field or not.
Text views introduce one additional complication: if the focus is in the text view, pressing "return" will not invoke the button action. It will just insert a return into the view's text.
What I did is often a good way to figure out strange problems like this: create a small app that does no more than necessary, and then poke around at it to see how it behaves. If the small app misbehaves (i.e. doesn't do what you expect), it's much simpler to tinker until you get it right. Once it works, you can then do the same things to the real app.
When the documentation is silent, just getting in and experimenting is often the best thing to do.
|P.S.: I have many problems associated with TextFields. For example,
|today I could not setDelegate for any TextFields. I could connect the
|delgate in Interface Builder but the delegate methods never get called.
|I am certain the delegate methods are working because they are also
|connected to two TextViews and they get called correctly by them (i.e.,
|I set the delegate for many objects to one class but the set does not
|work for any TextField objects).
Do you know that the *set* isn't working? That is, if you print "[textview delegate]", do you get your delegate object? More likely, the problem is that the delegate methods for text fields are different from those for text views; delegates for text fields and delegates for text views aren't automatically interchangable. Text fields send the generic NSControl messages to their delegates (e.g. control:textShouldBeginEditing: and controlTextDidChange:); text views send text-view-specific messages (e.g. textShouldBeginEditing: and textDidChange:). Unless your delegate responds to *both* sets of messages, it will do just what you're seeing. (There's very little that text fields and text views have in common beyond the fact that they both store text.)
Glen Fisher
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.