I have a custom NSTextField and I need to know which control is "active" when/after controlTextDidEndEditing is fired. The FirstResponder of the window is still on the TextField when controlTextDidEndEditing is called.
I solved this with the object that is accessible via the key _NSFirstResponderReplacingFieldEditor in the notifications userInfo.
Related
How do I implement my own selectAll: for UITextView without subclassing it? I don't want to subclass UITextView because if I do I need to change every place in my codes (.m/.xib) that need to use this subclass.
I had thought (wrongly!) that maybe I can connect UITextView action like selectAll: to my code (I do declare - (IBAction)select:(id)sender in my h file) ? I drag the action to File's Owner or to .h/.m file, nothing happens.
Now I know they are received action so I can't do that. Then how to ?
You cannot connect it because there is no such action. You are reading the Connections inspector incorrectly. The things in your screen shot are not actions. selectAll: is not an action. It is a received action. It is not emitted by the text view. It is sent to the text view, as a nil targeted action passing up the responder chain. To change or add to the text view behavior when it receives this action, you subclass UITextView. It's easy to do.
I have a simple uicollectionviewcell with some buttons and a uitextfield. Tapping the uitextfield pops the keyboard but my Done button makes the keyboard 'blink' and then the uppercase arrows fill in. Weird.
None of my uitextfield methods are called (I have them logged). The uitextfield is in the nib file and I tried setting delegate in code and in IB. Neither work but doing it in IB causes a crash with no info other than ldb.
I also have the Return key set to Done.
Any solutions?
Turns out I was dragging the delegate to the files owner - it needed to be dragged to the cells view. Solved.
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.
So I'm building a program that features the use of the IKImageBrowserView component as a subview in an NSWindow. As a side note, I have a controller object called ImageBrowserController which subclasses NSWindow and is set as the delegate of the NSWindow object of my app.
I have sent IKImageBrowserView the message setCanControlQuickLookPanel:YES to enable it to automatically use the QuickLook functionality to preview image files when the IKImageBrowserView is a first responder to receive key events. Then it took me a while to figure out how to make the IKImageBrowserView a first responder which I finally got working by overriding acceptsFirstResponder inside my ImageBrowserController.
Now I understand that as the delegate to the NSWindow, ImageBrowserController has a place in the responder chain after the event gets triggered on NSWindow. And I understand that as a subview of NSWindow, IKImageBrowserView is in line to be passed events for event handling. What I don't get is where the connection is between the ImageBrowserController being a first responder and the event somehow making it to the IKImageBrowserView. I didn't set NSWindow or IKImageBrowserView as first responders explicitly. So why isn't it necessary for me to implement event handling inside my ImageBrowserController?
EDIT: So after reading the accepted answer and going back to my code I tried removing the acceptsFirstResponder override in my ImageBrowserController and the QuickLook functionality still triggered just like the accepted answer said it would. Commenting out the setCanControlQuickLookPanel:YES made the app beep at me when I tried to invoke QuickLook functionality via the spacebar. I'm getting the feeling that my troubles were caused by user error of XCode in hitting the RUN button instead of the BUILD button after making changes to my code (sigh).
Some of what you are saying regarding the interactions between your objects does not make sense, and it is hard to address your stated question without some background.
As you say, your window delegate has a place at the end of the responder chain, after the window itself. The key point I think you are missing is that GUI elements, such as your IKImageBrowserView, will be at the beginning of the chain, and any one of them in a given window could be the current firstResponder.
When your application gets an event, it passes it off to the key window (which is just the window which currently accepts "key" (i.e., "keystroke") events). That window begins by asking its firstResponder to handle the event. If that object refuses, it passes the event to its own nextResponder, usually its superview, which either handles it or passes it on, until the event has either been handled or passed all the way up to the window object itself. Only then will the window (if it does not handle the event itself) ask its delegate to handle the event.
This means that the connection between the window delegate and the IKImageBrowserView is only through the Responder Chain, and its nature is simply that if the view declines to handle any given event, the delegate may eventually be asked to handle it, if no other object in between them handles it first.
Your window delegate does not need to be a firstResponder. Nor does overriding acceptsFirstResponder on the window delegate have any effect on one of the window's subviews.*
Your window delegate also does not need to (and, indeed should not) be a subclass of NSWindow. All it needs is to be a subclass of NSObject which implements whatever methods from the NSWindowDelegate Protocol you are interested in, and methods to handle any events you might want to catch if they are not handled by other objects.
So, the answer to your explicit question at the end is (and I do not mean this sarcastically): you only need to implement event handling in your window delegate if you want it to handle events itself.
*: IKImageBrowserView already responds YES to acceptsFirstResponder. If there are no other subviews in your window, it will automatically be the firstResponder when your application starts. You can set this initialFirstResponder explicitly in Interface Builder by connecting that outlet on the window to whatever object you want.
How can i get a notification if a NSView gets the key focus?
I expected a method like "windowDidBecomeKey" from NSWindow but either i'm blind or there is nothing like this is NSView.
The key view, when there is one, is the first responder. So, implement the becomeFirstResponder method in your view, and either handle that there or post a notification for your controller to listen for.