Let me summarize this shortly: A "First Responder" in a nib file is an object, which represents the UI control element that has the user's focus. So if the user clicks on a control, the nib sets that clicked UI control as First Responder. In my app I could make an outlet to that "First Responder" from the nib, so that I could for example send a message "make red font color" to whatever the user has activated by clicking.
And then, if this First Responder UI control does not understand that message, the message gets passed up in the responder chain, until a parent element or grandparent (and so on) UI control element understands the message. Otherwise it will be ignored.
So First Responder always establishes a "link" to the UI control that has focus. Is that right?
Right overall picture, wrong implementation details in the first paragraph.
A "First Responder" in a NibFile is an Object …
No, actually, First Responder is nil. Connecting a UI control (e.g., button) to First Responder in a nib is equivalent to [control setTarget:nil] in code.
The reason for the First Responder fake-object in the nib window is that, in IB, you set target and action at the same time (ctrl-drag to target, choose action from pop-up menu). You can't set the action and leave the target unset, like you can in code, so to set it to nil, you need to do so explicitly. That's what First Responder is for: it's a fake object representing nil, so you can set the target and action the same way you would do when setting it to a specific real target.
Of course, you can't use this to set anything else to nil, only views' targets. You can only use it to mean First Responder, not anything else.
So if the user klicks on an UI control, the Nib sets …
The nib doesn't do anything. It's just a freeze-dried collection of objects stored on disk. Even when you instantiate NSNib, all you're doing is defrosting some objects. It's the objects that do things.
In the case at hand, when you unarchive the control you connected to First Responder from the nib, its target is set to nil (remember, that's what First Responder really is: a target of nil). When a control's target is nil, and the user clicks on it, it sends its action to whichever responder is the first responder at the time.
Your second and third paragraphs are correct.
Your understanding is incomplete. The responder chain includes more than what we'd usually think of as "UI controls," including most importantly the current document. One of the big benefits is that it allows you to interact with the conceptually "current" whatever — current window, current text field, current document, etc — without a lot of messing around to find it.
A responder is any object that will perform actions (call functions) when events (such as clicking on buttons) occur. The responder chain is a sequence of objects each contained in one another - for example a button inside a panel inside a window. When an event occurs, we iterate through the chain until we find an object that does not have a responder set to nil and which can therefore respond to the event. So instead of providing a responder object for each button in a window, we can provide a single responder for the whole window. The first responder is simply the first object inside the responder chain - linking an event to the first responder allows the event to pass up the chain.
Check this link out it does a good job explaining. I think you have the gist of it:
http://cocoadev.com/FirstResponder
From the source:
The FirstResponder is the first object
in the responder chain that is given
the opportunity to respond to an event.
Related
I have a document-based Cocoa (Mac)/Objective-C application. I'm showing a popover on one of the views in my document window's view; the popover contains only an NSTextField, whose target is the first responder (I have also tried wiring it directly to the File's Owner, which is the document) and whose action is a selector that my NSDocument subclass responds to.
Problem is, when I press return in my field, it just beeps at me. It does not appear to send the action to the document. The document certainly doesn't receive it.
(I can type into the field just fine, but when I want to send the field's action, it refuses.)
There are no exceptions logged in the debugger console.
I have confirmed (by breaking in the debugger in validateUserInterfaceItem: and then opening a menu) that the field's target and action are set as expected. I did a Find using the selector reported by the debugger in my document class to confirm that the selector is indeed correct (no typos).
I'll note that validateUserInterfaceItem: isn't called on the return key-press. I don't remember whether it's supposed to get called by text fields or not.
I have read some questions and I find some very confusing and I don't really know if they answer my question.
I have an NSCollectionView implemented and connected to a Core Data context, everything shows correctly.
Now what I have is buttons in the view prototype, and when I click this buttons I need to get the value of the representedObject of that cloned view.
I have read and read and some parts are confusing to me, so I'm looking for a simple explanation.
Thank you for your time.
An action method takes one argument:
- (IBAction) collectionViewButtonClicked:(id)sender {
}
That sender is the control or other UI element (e.g., menu item) that sent the message.
With that argument, when your action method gets called, you know which button was clicked.
A button is a kind of control, and every control is backed by at least one cell. Cells have represented objects, too.
So, first, set the represented object of your button's cell to the collection view item that owns the button. (You can do this in the nib editor.) Then, in your action method, get the button's cell, then the cell's represented object (which is the item), then the item's represented object.
If the representedObject outlet doesn't show up in the nib editor, you probably have the button selected, not its cell. I recommend opening the nib editor's outline view using the button in the lower-left and then never, ever closing it.
View-based NSTableViews seem to have just the standard behavior, where, in order to make a text field inside the table the first responder, the user has to either double click or to single click and "keep calm".
However, given the flexibility view-based NSTableViews offer, this behavior is not not always desirable since there are now much different and complex applications possible than just doing an "old school" table.
How can I easily make a control (possibly in a cell together with other controls) inside a view-based NSTableView the first responder by a single click?
To solve this, override this method on NSTableView:
#interface NSResponder (NSControlEditingSupport)
/* This is a responder chain method to allow controls to determine when they should become first responder or not. Some controls, such as NSTextField, should only become first responder when the enclosing NSTableView/NSBrowser indicates that the view can begin editing. It is up to the particular control that wants to be validated to call this method in its -mouseDown: (or other time) to determine if it should attempt to become the first responder or not. The default implementation returns YES when there is no -nextResponder, otherwise, it is forwarded up the responder chain. NSTableView/NSBrowser implements this to only allow first responder status if the responder is a view in a selected row. It also delays the first responder assignment if a doubleAction needs to (possibly) be sent. 'event' may be nil if there is no applicable event.
*/
- (BOOL)validateProposedFirstResponder:(NSResponder *)responder forEvent:(NSEvent *)event NS_AVAILABLE_MAC(10_7);
#end
And return YES right away to allow the firstResponder to be made quickly. The table "delays" making the first responder if a text field was hit, and doesn't allow it to be made unless the row was selected first.
I would like to enable the grayed out open file menu item within a non-document-based application. Document-based applications automatically give you a nice open file dialog with file extension filters based on plist entries etc... Surely, a simple elegant method exist to re-enable this functionality.
I have...
Added document types to the project properties window
Assigned my controller class as the application delegate
Added the delegate application:openFile: to my controller class
First, make sure your File->Open menu item's selector is connected to the openDocument: action of the First Responder.
Second, make sure you are responding to the action. Take a look at the Responder chain of a non-document application with an NSWindowController object. Any object within your responder chain can respond to the message, but it is best to pick the object which is the most capable and appropriate. Once you have decided which class in your responder chain is the most appropriate to handle the message, add the openDocument: action to it's implementation and write your code to respond to it accordingly.
The key is that something along the menu item's responder chain has to respond to the -openDocument: action. Normally it's the NSDocumentController. I'd take a look at how an empty document-based application sets up that menu item.
Let me summarize this shortly: A "First Responder" in a nib file is an object, which represents the UI control element that has the user's focus. So if the user clicks on a control, the nib sets that clicked UI control as First Responder. In my app I could make an outlet to that "First Responder" from the nib, so that I could for example send a message "make red font color" to whatever the user has activated by clicking.
And then, if this First Responder UI control does not understand that message, the message gets passed up in the responder chain, until a parent element or grandparent (and so on) UI control element understands the message. Otherwise it will be ignored.
So First Responder always establishes a "link" to the UI control that has focus. Is that right?
(Exact duplicate of "First Responder" - Did I get that right? by the same author)
The first responder is simply the object that will be told (and given a chance to respond) to an event (such as a mouse click) in your application.