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
Related
I am developing a small and simple status menu application.
There is a menu and when the user clicks on it, a HUD window (NSPanel) should appear.
This is how I show the panel:
[hudWindow makeKeyAndOrderFront: self];
This is how I dismiss the window:
[hudWindow orderOut: nil];
So that's the events chain:
When the app starts I dismiss the window;
Then the user (that's me :-)) clicks on the menu item and makes the panel appear;
Then I click on the x and close the panel;
Then I click again on the menu item and the window doesn't appear again.
It doesn't appear again probably because it gets deallocated, and I have put a weak storage, otherwise with __unsafe_unretained it would crash at the second launch.
So I'm guessing if there's a way to avoid deallocating the window when the user clicks on it.
I have tried with a strong storage but this case at the second launch I'm unable to close it again and that's a problem.
There are many menu status applications that are able to display a window without that the user can "kill" it, I would make something of similar.
You should uncheck the "Release When Closed" checkbox in IB (or done the equivalent in code). That box is checked by default for panels.
Using a strong pointer probably doesn't work because the releasedWhenClosed setting overrides that. Having a strong pointer just means that the retain count will be at least one, but that doesn't prevent the system from explicitly sending a release message to the panel.
Can't you just change your property from weak to strong?
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 need to implement a custom popover (cannot use NSPopover). Its all working fine, but I also need to implement that the popover closes itself when the user clicks somewhere in the parent window.
What's the best way to implement this, resp. how could this be implemented without subclassing the parent window?
Make the popover key window when showing it, and use NSWindowDidResignKeyNotification (or the delegate method) to close when it resigns that status (which happens when user makes some other window active). Closing whenever the parent window is closed is also a good idea (NSWindowWillCloseNotification).
Hi need a little help, i have a window which is set to always show in the top right corner but it is not set to always key. The window has a few buttons on it and when a button is clicked the window becomes key, but what i want it to do is when a button is clicked i want the window to remove itself from being key.
So ideally the window becomes key when a button is clicked and in the method which the button calls i want to write a statement which will then perform the action of the button and remove the window from key.
However the window is declared under the app delegate and the method linked to the button is declared in a separate header file.
Anyone have any ideas how i can do this, any help would be much appreciated.
Thanks in advance, Sami.
There are a few solutions depending on the architecture of your application.
Send [[NSApp mainWindow] makeKeyWindow], which will make the main window become key.
Your application delegate could have a reference to the main window. In the action method that handles the button click, you could ask the application delegate to make the main window become key. The application delegate would send [mainWindow makeKeyWindow].
Your application delegate could have a reference to the window controller that manages the main window. In the action method that handles the button click, you could ask the application delegate to make the main window become key. The application delegate would ask the main window controller to do that, and the main window controller would send [[self window] makeKeyWindow].
Your application delegate could listen to the NSWindowDidResignKeyNotification notification and keep a reference to the last window that resigned being key. In the action method that handles the button click, you could ask the application delegate to return key status to that previous window. The application delegate would need to ignore NSWindowDidResignKeyNotification notifications when the window is your auxiliary window. This solution is better when there’s no single main window.
If the first solution is not applicable, a) your application delegate could conform to a protocol that declares a method responsible for restoring key status to the proper window, or b) your action method could post a notification informing the application that your action method has completed, and have the application delegate listen to that notification and restore key status to the proper window.
Note that even though I’ve suggested that the application delegate would implement the behaviour of restoring key status, other objects could be responsible for that. This is particularly easier when notifications are used since there’s no need to grab a reference to the object that will restore key status due to the inherent loose coupling provided by notifications.
I am used to programming for the iPhone. There, I would connect a button to an action, and then a method by creating the method like so: -(IBAction) DoStuff{…}. Then I would make an outlet for the button, and then the actual button in Interface Builder. I would then connect the button to the outlet, and then connect the button to the action by clicking on the circle next to Touch Up Inside and drag it over to File's Owner and select my action.
I am new to programming for the Mac, so I tried to drag from performClick to the file I wanted, but it wouldn't let me make the connection. Do I have to do this programmatically or what? How do I get this button to trigger an action in my code?
The fundamental difference is that iOS controls can have multiple actions for different events, but Mac OS X controls only have one primary action (in some cases, there are others that can be set up programatically).
When you right-click on a button in a Mac nib, performClick: is under Received Actions; it’s not an event. The only entry under Sent Actions is “selector”, which is the only thing you can connect to an action on another object.
Because there is only one “sent event”, you’ll normally just control-drag/right-drag from the control to the target and select the action rather than control-clicking, selecting the event and dragging from that.
It works much the same, but unlike UIKit there is only one signature for actions:
- (IBAction)actionName:(id)sender;
See Communicating with Objects and Target/Action in Interface Builder for more.
I like to Control-Click on the button and then drag to the object that I want to recieve the action. I then select the method of possible choices from the popup menu.