I have an NSDocument based app which also has a preferences NSPanel window. The preferences panel can then pop an NSFontPanel to configure a default font for my app. Challenge I have is that when the NSFontPanel is displayed, it becomes 'key' - which means the responder chain will direct changeFont: messages to the 'main' window (i.e. my document NOT my preferences panel)
Anyone know how this scenario should be handled? I guess, what I want is for the changeFont: message to goto the 'topmost non-key window' in this situation. I could do a quick check in my main window to check if preferences panel is visible and pass the message on - but that feels hacky...
Any suggestions would be most welcome!
You can use the NSNotiFication by sending your changeFont: messages
Related
I am showing a floating NSPanel (separate from the main application window) for inputing data (I should add, this is a UIElement application but not a background one, i.e. it has no main window per say, and responds to global keyboard shortcuts to launch a window). I want certain keyboard shortcuts to work specifically for this NSPanel in addition to the ones the main menu supports for the application window.
How can I set a NSMenu for the floating panel such that keyboard shortcuts are sent to this panel when it's a keyWindow?
The simple solution was to simply implement the menu actions in the NSViewController hosted by the panel. This would then get picked up in the responder chain for all keyboard shortcuts supported.
I am developing cocoa application having multiple windows. There is a red close button on left corner of window. And I want to handle click event of close button so that I can show message to ask user whether he wants to close window or not. If user accept to close window then application will be terminated otherwise same window shown to user.
Any idea how can I handle click event of close button???
Please look at NSWindowDelegate protocol reference, the method which you are looking for is-
- (BOOL)windowShouldClose:(id)sender
NSWindowController has a method
- (BOOL)shouldCloseDocument
I have come across this Cocoa application (source code) that shows a main Window.
As long as this window is key it is possible to open the Preferences window from the Main menu as well as by hitting Command-, but when the main window is not key and another window from the same app is, the NSMenuItem is grayed out and the keyboard shortcut does not respond.
I've inspected the xib file associated to the Main Menu and that NSMenuItem is sending a openPreferences:(id)sender IBAction to the FirstResponder which sould be the NSApplication.
What am I missing (I am still a newbie at mac cocoa programming)? How can I fix it so that the preferences are reachable from each application window?
Probably the original author implemented - (BOOL)validateMenuItem:(NSMenuItem *)menuItem and returns NO under some circumstances.
NSMenuValidationProtocol documentation.
Update: Another quick guess: Maybe the object that handles the IBAction for the menu item is not in the responder chain anymore after you open the second window. NSMenuItems are only enabled if the action selector can be found in the responder chain.
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?
After creating a translucent window (based on example code by Matt Gemmell) I want to get keyboard events in this window. It seems that there are only keyboard events when my application is the active application while I want keyboard events even when my application isn't active but the window is visible.
Basically I want behavior like that provided by the Quicksilver application (by blacktree).
Does anybody have any hints on how to do this?
There are two options:
Use GetEventMonitorTarget() with a tacked-on Carbon run loop to grab keyboard events. Sample code is available on this page at CocoaDev.
Register an event trap with CGEventTapCreate. Sample code can be found in this thread from the Apple developer mailing list.
Edit: Note that these methods only work if you check off “Enable access for assistive devices” in the Universal Access preference pane.
A simpler route that may work better for you is to make your app background-only. The discussion on CocoaDev of the LSUIElement plist key explains how to set it up. Basically, your application will not appear in the dock or the app switcher, and will not replace the current application's menu bar when activated. From a user perspective it's never the 'active' application, but any windows you open can get activated and respond to events normally. The only caveat is that you'll never get to show your menu bar, so you'll probably have to set up an NSStatusItem (one of those icon menus that show up on the right side of the menu bar) to control (i.e. quit, bring up prefs, etc.) your application.
Edit: I completely forgot about the Non-Activating Panel checkbox in Interface Builder. You need to use an NSPanel instead of an NSWindow to get this choice. This setting lets your panel accept clicks and keyboard input without activating your application. I'm betting that some mix of this setting and the Carbon Hot Keys API is what QuickSilver is using for their UI.
Update:
Apple actually seems to have changed everything again starting with 10.5 BTW (I recently upgraded and my sample code did not work as before).
Now you can indeed only capture keydown events setting up an event tap if you are either root or assistive devices are enabled, regardless on which level you plan to capture and regardless if you selected to capture (which allows you to modify and even discard events) or to be listen only. You can still get information when flags have changed (actually even change these) and other events, but keydown under no other circumstances.
However, using the carbon event handler and the method RegisterEventHotKey() allows you to register a hotkey and you'll get notified when it is pressed, you neither need to be root for that nor do you need anything like assistive devices enabled. I think Quicksilver is probably doing it that way.