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.
Related
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.
I have an NSPanel with a NSOutlineView to display my data. I want to select a row with a first click inside the NSOutlineView even if the panel is not in focus (i.e. not the key window) I have a delegate that allows selection and I have overridden the NSOutlineView class to override the acceptsFirstMouse: method, but I could not get the first click selection.
I checked the mouseDown event and it fired without any problems (in my class that overrides) when the panel was and wasn't the key window. But when the panel is not key, NSOutlineViewDelegate method shouldSelectItem: is not called.
What am I missing/doing wrong?
You just need to subclass your NSTableOutlineView and override:
- (BOOL)needsPanelToBecomeKey
to return NO.
NSView class reference states:
Overridden by subclasses to determine if the receiver requires its
panel, which might otherwise avoid becoming key, to become the key
window so that it can handle keyboard input and navigation.
Discussion
Such a subclass should also override acceptsFirstResponder
to return YES.
This method is also used in keyboard navigation. It determines if a
mouse click should give focus to a view (make it first responder).
Some views will want to get keyboard focus when you click in them, for
example text fields. Other views should only get focus if you tab to
them, for example, buttons. You wouldn't want focus to shift from a
textfield that has editing in progress simply because you clicked on a
check box.
Source: Apple documentation
I have a transparent NSWindow that follows the user's screen everywhere he goes (the NSWindowstays in front of every app, no matter what, even fullscreen apps).
In that NSWindow i have a mouseDown event that shows a popup. Let's say i'm on safari in fullscreen mode and i have my Window in front of it, i click on safari and i click again on my Window: nothing happens, the mouseDown doesn't occur. I have to click again so the mouseDown event is triggered.
How can i force my NSWindow to be always active so i don't have to click it 2x to trigger the mouseDown when i click on a background app and click in my window again?
Thank you!
I'm not sure if this is exactly what you want (it's not quite a window wide setting), but, from the documentation:
By default, a mouse-down event in a window that isn’t the key window
simply brings the window forward and makes it key; the event isn’t
sent to the NSView object over which the mouse click occurs. The
NSView can claim an initial mouse-down event, however, by overriding
acceptsFirstMouse: to return YES.
The argument of this method is the
mouse-down event that occurred in the non-key window, which the view
object can examine to determine whether it wants to receive the mouse
event and potentially become first responder. You want the default
behavior of this method in, for example, a control that affects the
selected object in a window.
However, in certain cases it’s
appropriate to override this behavior, such as for controls that
should receive mouseDown: messages even when the window is inactive.
Examples of controls that support this click-through behavior are the
title-bar buttons of a window.
Or you could try fiddling with
- (void)sendEvent:(NSEvent *)theEvent
and see if you can handle events in a custom way.
If you add a borderless NSButton instance to your window's view and set your image as the button's image (and as its alternate image, to make it more beautiful), it will work out of the box: Just connect the button's action method to your app delegate (or the object where you want to process the click action). A click on the image (i.e. the button) will then trigger the button's action method, no matter which window is active.
This worked for me, hope that will be helpful, This will keep your window always on Top of all applications
[self.window makeKeyAndOrderFront:nil];
[self.window setLevel:NSStatusWindowLevel];
I think what you really should do is use an NSPanel (a floating palette -- a special kind of NSWindow) that will do exactly what you want in a way that's consistent with the OS rather than trying to fight intended behavior.
Here's the NSPanel documentation:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nspanel_Class/Reference/Reference.html
And here's some helpful and pithy information:
http://cocoadev.com/wiki/NSPanel
By default, an NSPanel will disappear when the application is inactive, but you can turn this off.
I apologize for not laying it out more fully ... pressed for time.
Edit:
Note that you can probably get your window to behave as desired simply:
"The NSView can claim an initial mouse-down event, however, by overriding acceptsFirstMouse: to return YES."
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html
You'll need to do this with any NSView subclass to skip the "activation click".
I am writing a notification system just like growl. The notification is a window and it's level is set to NSModalPanelWindowLevel. The only problem is, I have a button in that window and when the user wants to click that button, he/she has to click it twice. But, for example, in growl, no matter what window you have opened, you just simply click the notification and it registers a click.
So is it a level problem? If so, what should I set it to? Thanks
In your custom controls that make up the view content of the window, you will likely want to override NSView's -acceptsFirstMouse: method to return YES:
Discussion
The receiver can either
return a value unconditionally or use
the location of theEvent to determine
whether or not it wants the event. The
default implementation ignores
theEvent and returns NO.
Override this method in a subclass to
allow instances to respond to
click-through. This allows the user to
click on a view in an inactive window,
activating the view with one click,
instead of clicking first to make the
window active and then clicking the
view. Most view objects refuse a
click-through attempt, so the event
simply activates the window. Many
control objects, however, such as
instances of NSButton and NSSlider, do
accept them, so the user can
immediately manipulate the control
without having to release the mouse
button.
Not sure if this is what Growl does, but you might be able to listen for mouse over events in the window and use them to activate/deactivate the window prior to the click. I suspect your issue is that the first click is being eaten by the activation of the window.
Just a guess on that though.
To learn how to handle mouse over events, check out this documentation:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html
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.