I have a Cocoa application I am building which contains an NSSearchField control. I want to enable a keyboard shortcut / key equivalent so when the uses presses COMMAND-OPTION-F, the search field gets focus.
However, after much searching, it is not clear to me what the best way to implement this is. There is not an option to set this for the NSSearchField in Interface Builder.
Is the solution to subclass NSSearchField and listen for the keyDown event (and then see if the key equivalent is pressed?)
You can always add a menu item with a key equivalent of ⌘⌥F i.e. CommandOptionF. In the menu's action, just manually make the search field the first responder using
[window makeFirstResponder:searchField];
Related
I need to detect whether any NSControl, such as an NSButton, can get the focus by using the Tab key.
It can, if the user has enabled the option in the System Preferences under Keyboard / Shortcuts / Keyboard / "Change the way Tab moves focus".
More specifically, I like to make a NSButton the first responder but only if the "all controls can get focus" mode is enabled. Maybe I could ask the control if it accepts the firstReponder status?
I tried calling acceptsFirstResponder on a button, but that returns YES even if it can't become firstReponder by using the Tab key, so that's not the right way.
canBecomeKeyView is the property/method you're looking for.
From Cocoa Event Handling Guide, Keyboard Interface Control
The acceptsFirstResponder method controls whether a responder accepts first responder status when its window asks it to (that is, when makeFirstResponder: is called with the responder as the parameter). The canBecomeKeyView method controls whether the Application Kit allows tabbing to a view. It calls acceptsFirstResponder, but it also checks for other information before determining the value to return, such as whether the view is hidden and whether full keyboard access is on.
I am having a devil of a time trying to figure out how to get the address of the Text Field Editor (NSTextView) of an NSCell—NSFormCell and NSTextFieldCell in particular? NSCell does not have a property to access it. I did figure out the editor is not allocated until one is actually editing the field.
I want to set the delegate so I can capture keystrokes for auto-completion.
By default, there's a single field editor for each window. Even if a control or cell uses a custom field editor, it's still vended by the window. You would call -[NSWindow fieldEditor:forObject:] to obtain the field editor for a given control.
However, the delegate of the field editor is always set to the control on whose behalf it is working. Setting the delegate to something else is likely to break things. So, you would typically use a custom subclass of the control and implement your delegate methods there.
Finally, controlling completions is normally done using -textView:completions:forPartialWordRange:indexOfSelectedItem: in the text view delegate, not by capturing keystrokes.
In my application I have an NSSearchField that is bound to an arraycontroller which performs searches as the user types.
The problem is that the search field never resigns firstresponder-status once it receives it.
What would be the cleanest way of resigning firstresponder status when the user presses Enter or clicks outside of the search field? If possible I would prefer to do as much work as possible in Interface Builder.
[searchField.window makeFirstResponder:nil]
If you just want to get rid of the focus ring, you can disable it in the NIB.
If you want to resign first responder when the user clicks empty space in the window, you have to use a custom NSView as the window's content view and override mouseDown: to call the above method.
I'm trying to capture all the NSTextFinderClient calls on my custom NSTextView subclass.
The show action is called on my -(void)performTextFinderAction:(id)sender override, but for find next, find previous, etc. it's not called.
Any ideas?
Thanks!
Edit:
If you create a new project and drag an NSTextView from interface builder, command-g and command-shift-g (find next and find previous) don't work when the find bar is first responder.
Why is this?
I need a custom subclass of NSTextView to respond to the find bar for every event.
I searched in the Apple's TextEdit source code because with TextEdit, the standard search bar within the Text View works fine for command-G (and other shortcuts) even the search field is the first responder.
I found the solution.
Go to your nib for the main menu, and select the "Find" (and related) menu items. They should be bound to the default action called "performFindPanelAction:." Now unbind them and bind to "performTextFinderAction:" of the First Responder instead.
You may not find that action in the First Responder's action list. So you need to add it by yourself in the First Responder's attributes inspector pane.
This was meant by the document below saying
Before OS X v10.7, the default action for these menu items was performFindPanelAction:. Whenever possible which you should update your implementation to use this new action.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/#//apple_ref/occ/instm/NSResponder/performTextFinderAction:
The find bar communicates privately with the client's NSTextFinder instead of calling NSResponder's -performTextFinderAction:. This is necessary to allow find to work when something besides the client has key focus.
What are you trying to accomplish?
I need to capture undo/redo key commands in an NSTableView and forward that down to a managed object context's undo manager. I have tried overriding -keyDown, but that's hard to navigate. I really need an internationalized solution to this problem that doesn't revolve around checking for the "z" key with the command key modifier mask.
Is there a way I can set up my tableview to look for the standard "undo" key binding? Any ideas?
Implement windowWillReturnUndoManager in the delegate of the window containing your NSTableView. Then return your object context's undo manager there. Then your table view will be able to receive those events.
[NSWindowDelegate windowWillReturnUndoManager:]
You generally use NSUndoManager in Cocoa apps for handling Undo/Redo events. For more information, refer to http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUndoManager_Class/Reference/Reference.html