My Cocoa app displays a transparent window on the screen, but when the user tries to take a screenshot using Mac OS X's built-in screen capture key with the option of selecting full windows (Command-Shift-4, then Space Bar), my window gets highlighted as part of the possible windows to capture.
How can I tell my Window or App not to allow this? My Window already refuses to be the Main Window or Key Window through -canBecomeKeyWindow and -canBecomeMainWindow both returning NO, but this still happens.
The Window is also at the NSModalPanelWindowLevel and NSScreenSaverWindowLevel does the same thing.
Notice that every window is eligible for screenshots, even the desktop, dock and menu bar, which are special windows. You can even take a screenshot of the Exposé overlay window itself. This leads me to believe that there is no way to do this.
I suppose you could hook the Command+Shift+4 key event and hide the window, but that key combo is user-definable, so it is subject to change.
Related
When I click the application shortcut, if the program is already open, I will show the program and enable FlashWindow. (FlashWindow(true);)
After blinking once, the taskbar is highlighted.
Theoretically, clicking on the application window would unhighlight the taskbar.
But it doesn't.
There is no problem when the window is minimized.
But it doesn't work when the window is already displayed.
I tried to get all the window handles of the application based on the process id and activated them one by one, but that didn't work either.
For this step I printed the log and used GetForegroundWindow to confirm that the change did happen.
How to solve this problem?
Is there any other way to make the taskbar blink only once without keeping it highlighted?
Imagine I save my window's position in my preferences file. Now, the user moves the window to a second monitor, then quits my app. Then he disconnects the second monitor and launches my app again.
Now my app wants to restore the window's saved location. But if it blindly restores the old window coordinates, the window will be off-screen.
I used to use ConstrainWindowToScreen for my Carbon app, but now that I'm porting it to Cocoa, I can not find an equivalent for this.
The docs suggest that, somehow, Cocoa would automatically prevent this from happening. While that might be the case when the monitors change while the window is open, in my case where I've stored the window location myself and restore them when I re-open the window at launch, this isn't going to work. I need to invoke Cocoa's magic functionality on demand, but how?
(Note: I am aware that I could iterate over all available screens, but that's quite a pain to write myself if I want to get this foolproof. Still, if you can present a complete C or ObjC function that solve it this way, that'd be appreciated, too.)
See the "Managing Window Frames in User Defaults" section in the NSWindow Class Reference. Those methods ensure that a window will be placed entirely on screen.
If you want to save and restore the window location yourself (as a string), use -stringWithSavedFrame and -setFrameFromString:.
Use -saveFrameUsingName: and -setFrameUsingName to have NSWindow save and restore its frame in the user defaults, given a window name.
I agree with Darren's suggestion to use the built-in mechanism for restoring window positions. Really, it's as easy as setting a window's frame autosave name in IB (or with -setFrameAutosaveName:).
That said, if a window has a title bar, then all of the methods which order it onto the screen (e.g. -orderFront: or -makeKeyAndOrderFront:) will automatically reposition it to make sure at least the title bar and a significant chunk of the window is on the screen. It's honestly difficult to get a titled window to be theoretically visible but actually off-screen.
I have other application's fullscreen direct-x window, which I need to hide. I found the way to hide it by hooking direct-x create device and changing window parameters so it is not fullscreen. This works ok on XP but on Win-7 I can't use any other application because it looks like application is switching it to be foreground window so all clicks and keyboard input goes to that window. However if I click fast I can make some action. This make me think that this app is using some function to direct input to itself, or to focus, dunno what.
The other thing is that if I resize the window and don't hide it, all works ok.
I tried to hook SetCapture, SetForegroundWindow, SetActiveWindow and SetWindowPos and none of this helped.
Do you have some idea how can I hide window in other way, or what can cause this focusing to invisible window?
I was surprised this doesn't happen automatically, but I would like my applications window to be in focus as I click its dock icon, when in minimized mode.
Just to clarify, when I minimize the app, the window goes to dock, but when I click the its corresponding Dock Icon, the window don't come in focus.
Is there anything I am missing?
I am using Qt 4.5.3 on Mac OS X 10.5, 10.6
Thanks for help.
Rahul
First answer: That's the expected behavior of a Mac app. Try Safari for example. An app can be active without showing any window. In that case, only the menu bar at the top shows that the active app is changed. So, unless absolutely necessary, you shouldn't bring the minimized window back unless the user explicitly does so. That's the Mac way!
Second answer: I understand that there are cases where you want to bring the minimized window up. In Cocoa, the application delegate method -applicationDidBicomeActive is called when the application gets the focus, and there you can bring the window up yourself. I'm sure Qt also has a similar event/callback/signal or whatever, but I don't know any Qt ... :p Sorry I can't be of any help.
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?