In my app I've got a secondary NSWindow that's created from .xib in my NSWindowController in my initWithWindowNibName: method. The window is a plain NSWindow with the title bar switched off.
After creating the window it's shown using makeKeyAndOrderFront: -
and all controls are disabled (text field, combo box).
I have (more than..) triple checked all flags in the window and the view hierarchy of the controls: everything is enabled, allowing editing and not refusing to be first responder.
Totally clueless. Any ideas?
Update #1:
I appears the problem is related to the window not having a title bar. When the title bar is switched on the window - and the controls in the window - behave as expected.
As pointed out by Ken the framework will automatically refuse becoming a key window if the window title is switched off:
Attempts to make the window the key window are abandoned if this
method returns NO. The NSWindow implementation returns YES if the
window has a title bar or a resize bar, or NO otherwise.
A simple subclass did the trick.
Related
I've created a custom NSWindow which is borderless (Using NSBorderlessWindowMask style mask)
I want the window to be listed on the Window Menu (the list of windows shown when you right click on the app icon on the tray)
Note: Titled window with borders is automagically added to this list.
Do you know a way to solve this ?
Is it NSApp related thing ?
OK, i found a way to add window to the window menu manually using NSApp.
[NSApp addWindowsItem:window title:[window title] filename:NO];
I'm developing a small menubar application and I want to display the settings window when the corresponding NSMenuItem is pressed.
I currently have the following IBAction assigned to the menu item:
#IBAction func settingsButtonPressed(sender: NSMenuItem) {
settingsView.makeKeyAndOrderFront(sender)
}
This displays the window, but doesn't push it into focus, so it's displayed behind the currently active window, which is not the behaviour I'm looking for.
I had a suspicion that this might have been due to the fact that the Application is agent target property is set to YES, but this actually has no effect on the outcome.
Could there be anything to be done with the window in the XIB file?
Probably your app is not the active app. It should work to call [NSApp activateIgnoringOtherApps:YES] in addition to making the window key and ordering it front.
How can my menubar application achieve the same behaviours as 1Password or Dropbox:
clicking their menu bar icons or popovers does not steal focus, e.g. while I am in for example TextEdit and open 1Password/Dropbox, the blinking cursor disappears but the window itself does not go into the background, yet I can type into 1Password's text field.
even though they didn't take focus in the first place, they disappear when I click back into another application
I figured out how mouse over works in the Dropbox popover table view by using an NSTrackingArea with the options MouseEnteredAndExited, AssumeInside, and ActiveAlways.
I am trying to get the same behaviour to work in an NSPopover that opens from an NSStatusItem.
I found a workaround for now. I am able to get the same behaviour by using non-activating NSPanel with a window level kCGPopUpMenuWindowLevelKey and I had to override canBecomeKeyWindow to return true.
Unfortunately I haven't found a way yet to get a NSPopover to behave this way since it's not a subclass of NSWindow.
To set the kind of behavior you are describing you use:
yourPopover.behavior = .transient
I am creating an OS X application with multiple windows. The main window appears in the Window menu as expected.
I'm creating the 2nd NSWindow using initWithWindowNibName. It appears as expected when I call showWindow. However the window doesn't show up in the Window menu (under "Bring all to front" and the main window's name).
I tried:
[[NSApplication sharedApplication] addWindowsItem:[winController window]
title:#"The Window"
filename:NO]; }
I also tried:
[[winController window] setExcludedFromWindowsMenu:NO];
Neither of these seemed to help.
If you can't tell, I'm new to OS X (but I know Obj-C relatively well).
I figured it out. I was creating the window in a NSResponder's init function. Somehow it was happening too early and the sharedApplication wasn't ready yet. When I moved the window creation into an awakeFromNib everything worked as expected.
The Window Programming Guide says that "This menu automatically lists windows that have a title bar and are resizable and that can become the main window". Is there a reason that this window cannot become main, e.g., is it an NSPanel?
In one of my first Cocoa applications I have just a single window with 2 NSTextField instances - for user text input and of output of text processing.
If my user clicks on the red x on the top left, the window closes but the application is still running and icon stays in the dock - the normal Mac behavior.
When the user double-clicks on the icon in dock or on the desktop, this does not reopen the window - apparently also normal Mac behavior, but confusing to the user.
To get the app back into a running state, the user has to force Quit from the main menu or the context menu, and restart the app by clicking on one of the icons.
I searched Apple doc and forums, and it seemed that the following should prevent the closing of the window (my first preference : hide the widow so it can be reopened later) :
add a delegate to NSApp
delegate implements -applicationShouldHandleReopen which calls [mainWindow makeKeyAndOrderFront:self]; and returns TRUE
delegate implements -windowShouldClose which returns FALSE
However, although -windowShouldClose is called, the window closes.
What am I missing here?
As an alternative (my second preference), I added to the delegate
-applicationShouldTerminateAfterLastWindowClosed which returns YES
This works, i.e. the application closes when the used clicks on the red x,
and the user can restart the app later without further ado.
Clarifications and pointers to specific doc and working code examples would be appreciated.
Rudi
"When the user double-clicks on the icon in dock or on the desktop, this does not reopen the window - apparently also normal Mac behavior, but confusing to the user."
If you want the window to re-open in that case, implement applicationShouldHandleReopen:hasVisibleWindows:. There's nothing un-Mac-like about opening a window when the user clicks the dock icon after closing all the windows; lots of apps do it and the delegate exists specifically to support that behavior.
First of all, your "alternative" behavior of terminating the app on window close is probably the preferred approach for your situation. Users may be confused when they can't close the window.
If you really want to prevent the window from being closed, why not just disable the close control on the window in IB?