I successfully registered a hot key; its handler brings my app window to the front: [NSApp activateIgnoringOtherApps:YES]; (it is supposed to at least).
I have the expected behavior when my app window is in not in the front.
But it doesn't work when I close the window (clicking the red x) or when I minimize it (clicking the yellow -).
I still see the log though so the handler is called.
Any ideas?
Thanks.
-L
I would set the window to have the following attributes in the nib:
The key things are, if you plan on having the window open and closed several times, to make sure "Release when closed" is unchecked. You may also want to uncheck "Visible at Launch" to make it more clear that you'll handle the showing of the window yourself in code. (It's the presence of this flag which is likely responsible for your window being shown at all, immediately when the nib is loaded).
To show the window in code, just do something like the following (assuming you have an IBOutlet for window):
[window makeKeyAndOrderFront:nil];
You must explicitly tell the window to come onscreen. activateIgnoringOtherApps: does not open all previously closed windows.
Related
I'm using a NSPanel with HUD style to display some information.
There's a button inside the HUD panel, when the user clicks the button, I'll open a new window by calling:
[anotherWindowController showWindow:self];
[anotherWindowController.window makeKeyAndOrderFront];
And I want the panel disappear when the window shows, so I set the delegate of the main window, and in the windowDidResignMain callback, I called [hudPanel orderOut:nil].
The HUD panel did disappear (I can see it), but right after it closed, it reopens.
I've checked all possible orderFront: code, and none of them get called. So my hands are really tied. Is this a system level behaviour? Can anyone guide me through this?
EDIT:
I forgot to mention that, the button resides in a NSPopover. So, basically, there's a NSButton in the HUD panel. When user clicks the button, a NSPopover will show up, inside which, there's the button to bring up the new window.
Big thanks!
I had the problem. The following solved it:
[NSApp endSheet:yourPanel];
[yourPanel orderOut:self];
Use
[hudPanel performClose:nil]
(in Swift I have to use self instead of nil). I had a problem using orderOut with a popover and it was solved by using the above method.
Please add [hudPanel close] after [hudPanel orderOut:nil]
swift: hudPanel.close()
from the apple docs:
If the window is the key or main window, the window object immediately behind it is made key or main in its place. Calling orderOut(_:) causes the window to be removed from the screen, but does not cause it to be released. See the close() method for information on when a window is released.
Sometimes the window reappears during window controller inner logic, I think. I have an issue when long pressing keyboard button kills window, but shot keyDown event only hides it on the split second. After using close all goes smoothly.
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".
So I thought I had covered my bases, but apparently I'm missing a key step or two.
I have an NSPanel that is displayed (makeKeyAndOrderFront:) when an NSStatusItem is pressed. Things work great, but as the NSPanel displays a title bar, the panel is also draggable. (This is undesired.)
The first screenshot shows the panel with "Title Bar" enabled in Interface Builder, in the Appearance category. (Sorry for the blur, things are still under lock and key for now.)
The only change that is made in Interface Builder is unchecking the "Title Bar" checkbox. I then save and re-run, and that's what you see in the second screenshot. While a slight shadow appears, the panel does not.
Things I've tried:
I've subclassed the NSPanel and returned YES for canBecomeKeyWindow and canBecomeMainWindow after a bit of research, but (prior to subclassing) these methods both returned NO regardless of whether I was using a Title Bar or not. So I don't think this is the issue.
I've ensured that the frame for the NSPanel is properly set. It has a good height, and the origin is set properly as well.
Edit: Forgot to Mention:
The application is a menu-bar-only application. In the screenshot below, note that an additional entry was added to Info.plist to enforce this.
I've had problems with this in the past. I was able to resolve it by first "ignoring" other apps, then making it the key window. Give it a shot and see if it works for you.
[NSApp activateIgnoringOtherApps:YES];
[[self window]makeKeyAndOrderFront:self];
Also, try setting the window level to NSPopUpMenuWindowLevel during initialization.
[[self window]setLevel:NSPopUpMenuWindowLevel];
I have also had problems with the way that nib files are loaded on Mac OS X. They're loaded "lazily", which means that they won't be initialized until they're needed. This causes a problem when you're wanting to set specifics on the window, but you can't because awakeFromNib doesn't seem to be called, due to lazy nib loading. To fix this, here's what I've done in the past. In your delegate (or wherever you initialize your window), kick the window into action by accessing the window property on the initialized class:
wc = [[blah alloc]initWithWindowNibName:NSStringFromClass([blah class])];
(void)[wc window]; //just kicks the lazy nib loading into gear
By doing so, you're forcing the nib to initialize. That way, when the user clicks the menubar icon the nib is already initialized, and awakeFromNib has already been called.
While a slight shadow appears, the panel does not.
Are you saying makeKeyAndOrderFront: on this NSPanel object doesn't display it when running your app? I just created a sample project, NSButton triggers the same type of NSPanel to display, and it works fine.. titleBar enabled or not.
http://cl.ly/3d0U3C0P3u2D0m3T1w1N
I want to programmatically re-open the main window of my Cocoa application after the user closed it with the X button.
I know it's still somewhere in memory but I don't know where.
If you're using the default Cocoa Application template, your app delegate has a reference to the window that's in MainMenu.xib. You can simply call
[window makeKeyAndOrderFront:self];
perhaps in an IBAction triggered by a menu item, to reopen the window. Note: be sure that the "Release when closed" and "One shot" boxes are unchecked in IB.
Surely, if the user closes a window they want it to go away. Reopening a window they just closed will most likely annoy them. If you, the programmer, disrespect their wishes, they will probably disrespect your program by moving it to the Trash.
If you want to make it impossible to close the main window, disable the close button. You can do this easily in interface builder on the Window attributes inspector.