Is it possible to add hotkeys only when you're editing a certain NSTextField? For example, when you're in this text field I would like it if you pressed Command + 1 it inserted one string, and Command + 2 to insert another text string, etc, but only when you're editing that NSText field.
I tried adding a keyDown method to my subclassed NSTextField, but that didn't seem to ever get fired. If I changed it to keyUp it gets fired, but not if the command key is held down.
It seems when I'm searching for hotkeys the only information I find is on global hotkeys (ones that activate even when the app isn't visible) which isn't what I'm looking for.
If you had a menu item with that keyboard shortcut, you could implement validateUserInterfaceItem: to enable it when your field is in the responder chain. What I'm not sure about is whether that would work for a hidden menu item.
NSTextField's to not deal with keyDown: themselves. They instead seem to rely on intermediaries called Field Editors (found this info from a similar question here http://www.cocoabuilder.com/archive/cocoa/51299-custom-nstextfield-keydown.html).
Apple has some more info on the subject - http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TextEditing/Tasks/FieldEditor.html
I ended up subclassing my window and overriding sendEvent when my text field is the first responder.
Related
Background: I have a custom derivation of NSTextField that I am trying to use as a cell in a grid similar to a spreadsheet.
I have set the nextKeyView of my NSTextField and am confused between two states that the NSTextField can have BOTH of which involve it having the blue focus-ring drawn around it:
the cursor is blinking in it => in this case the TAB key behaves as expected and moves to the nextKeyView and it is in a "text accepting" mode
it has not quite "entered" the text field for the purposes of text editing => the TAB key does not respond with KIC behaviour and move to the nextKeyView and trying to enter any text just in fact results in the following:
-[NSEvent key]: unrecognized selector sent to instance 0x60800012bf40
From background reading and a bit of debugging it appears that the first state corresponds to control/focus being handed off to the window's shared text editor and the custom NSTextField actually loses firstResponder status in this process.
What's interesting is how this differs from the behaviour of two standard NSTextField controls dragged onto an NSView in Interface Builder. Running such a simple app only the first state above is present at all as you tab from one NSTextField to the other! I am glad to have the intermediate second state in my app (because I need it) but I don't understand why it is happening...
Summary: two related questions
How do I programmatically control the NSTextField entering these two states of effectively accepting text and not while it has the focus [I do not know how to achieve this at all so this is my main problem...]
How can I get the KIC behaviour in the situation where the NSTextField has the focus but is not in "text editing" mode since this is the behaviour I am trying to get. [My current conclusion is that KIC does not work in this situation and that standard practise would be to resort to the regular overriding of keyDown for the set of keys that would normally be associated with KIC.]
I'm working on a Cocoa application that has editable text fields. These text fields need to accept values but don't need to be spell checked or use any of the other options given in the default context menu. I've read that the easiest way to remove the right click/ opt + click context menu is to override the function:
rightMouseDown:(NSEvent *)
I've done this in a custom NSTextfield class. This fix blocks the user from right clicking when the text box is enabled and unselected, but as soon as the user double clicks/enters the text field for editing the default right click functionality returns.
Is this because the firstResponder switches to a class in the inheritance chain upon trying to edit the field? Is this approach the right way to disable all context menu functionality for this NSTextField?
Thanks!
When a text field is editing, the actual first responder is the "field editor", an NSTextView supplied by the window. The field editor always uses the control on whose behalf it is acting as its delegate.
So, in order to influence its behavior with respect to the contextual menu, you need to use a custom subclass of NSTextField. (I guess you already are to override -rightMouseDown:.) Then, implement the text view delegate method -textView:menu:forEvent:atIndex: and return nil (i.e. no menu).
So, I've been reading through other questions on here and Xcode's documentation, but I'm still a bit confused. Here's the scenario: I have a login screen for my app which has 3 text fields and 1 button. Each text field is bound to have a Return Key in IB: Next, Next, Go.
Now, how do I bind these return keys to actual actions where field 1 moves to the next, then field 2 moves to the next, and last field 3 triggers the button?
Some answers for similar questions suggest the use of textFieldShouldReturn method, but I'm still fuzzy on it. Somehow I can't see how it auto-magically knows what to do without having some kind of binding...
What you need to do is use an IBAction to select the next field when the return key is pressed. To do this, first add a method like this to your UIViewController. Make sure to add the method declaration to your header.
- (IBAction)selectSecondField:(id)sender
{
//_secondField is the IBOutlet to the second field
[_secondField becomeFirstResponder];
}
Build and then go to Interface Builder. Select the first text field and open the connections inspector (⌘2) and drag from the dot next to "Did End On Exit" to your controller with the action. A menu of actions will pop up, select selectSecondField.
You will need an action for each field. Alternatively, you could have one action and use sender to see which field was returned.
There's a handle (in the connections panel) on each text field called "nextfield" or something along those lines? (I can't remember off the top of my head) But if you drag that to the next box, that's how it knows (manually). I think generally it guesses using the X/Y location, but when you need to manually do it, just drag that handle.
I have a NSTextField object in my window which has to be disabled when a check box is clicked.
I have written a IBAction to receive the check box click and disabled/enabled the text filed based on the check box state.
[mName setEnabled: [mNameCheck state]];
This work fine with the basic functionality, but I found some strange behavior.
You update some detail in the text filed and click on check box the text filed get disabled old content.
Example:
Stage 1: Text filed has the content
"Name"
Stage 2: Update the text filed
content as "Girish"
Stage 3: Click check box (to disable
the text filed)
Stage 4: Text filed disable with the
content as "Name"
The issue get resolved if I resign the responder and set responder to some other controller before the text field is disabled.
In my case I can not assign the responder to check box(it does not take) or any other controller so I did some thing like bellow which works fine
[mName resignFirstResponder];
[mName becomeFirstResponder];
resign and assign responder with same controller.
I am just wondering is this solution is correct or any better solution to this issue?
As the docs state, do NOT call -resignFirstResponder or -becomeFirstResponder directly. Call -[NSWindow makeFirstResponder:] instead. It is acceptable to pass in nil and status will pass to the window itself.
You could try calling -[NSWindow selectNextKeyView:] although I'm not entirely certain what will happen if it doesn't find a valid next key view. Try it and see. If that doesn't work you'll have to fallback to calling -nextValidKeyView and -makeFirstResponder yourself.
If you set the text field to be Continuous in Interface Builder, the value of the field will be set as soon as a change is made in the field rather than when it loses focus. You can programmatically set this value with [yourTextField setContinuous:YES].
My app displays an NSWindow as a sheet. The NSWindow has various controls for settings properties of an object (an NSTextfield, a NSDatepicker etc) and two NSButton's, 'Add' and 'Cancel' which are used to confirm or cancel the action.
I have set the key equivalent of the 'Add' button to enter and the key equivalent of Cancel to escape. This does not have the desired affect. I think this is due to the other controls handling the keypress events.
How do I configure my sheet so that the buttons behave as described?
The solution is to not just check your work, but to double check it!
The setup as described in the question works perfectly. (I have two similar sheets and I was using the wrong one.)