In my mac application I am supporting full screen by changing system resolution of the device. And I am resetting back to old resolution if the user switches from full screen to windowed mode or if user quits the app and I need to handle force quit case also.
1. Is there any API or callback which tells the application if the user presses cmd+opt+esc(force quit).
2. Any other way to handle this?
I know in NSApplicaction there is an option to disable force quit([NSApplication setPresentationOptions: NSApplicationPresentationDisableForceQuit]) but instead of disabling it I want to handle force quit event.
The general consensus is that force quit sends a SIGKILL ("consensus" as I don't know any Apple documentation that states this, but it is the logical answer). A SIGKILL cannot be caught so you cannot do cleanup directly. An alternative is to run a helper application which monitors you main app and does the cleanup, the main app can terminate the helper on normal exit. See also this question.
Related
Users often forget to do a task which must be done before logging out. To help with this I'd like to create a popup on logout with an option to cancel logging off.
I'm open to using any language. AppleScript looks promising, although I have no idea how to go about detecting and canceling a logout.
Since writing the question I've discovered the quit handler fires on logging out. I've created a script showing a dialog in the quit handler, which does the job of cancelling a logout, but I'm left with an ugly icon in the dock.
I'm able to remove the dock icon using the "LSUIElement" property in "info.plist", however it no longer prevents logging out when this is set.
Normally, logout clean-up is handled by individual apps: e.g., a document-based app with unsaved changes might prompt the user to save documents first. That makes sense, because each app knows what does and does not need to be taken care of before it closes, while the system generally doesn't.
As you've discovered, if you create a front-facing app the system will poll it and give the app a chance to delay or abort logout. The system does not notify background apps, services, or accessories (on the assumption that only user input needs to be checked for persistence). If you set LSUIElement to 1, your app becomes a background app, and never gets the chance to interfere with logout. There's no easy or immediate way both to have such an app work and have it be invisible to the dock.
Maybe if you're more specific about what your goal is, there might be a workaround (e.g., if you're only interested in monitoring a specific app, that might be doable).
Application.Current.Exit() exits the app programmatically, but I need to simulate the same effect as when you press back out of you app, ie usually suspending it. Is it possible?
(yes I know you usually shouldn't mess around with this but it's for a very specific purpose)
No, it's not possible to exit an app programmatically without terminating it.
I'm a developer and a long-time Windows user with an obsession about making my system as convenient to use as possible.
Yesterday I thought about something that has always annoyed me in Windows and that I've taken for granted, and I realized that I have a better idea for how it could work, and I'm now wondering whether it's possible to tweak Windows to work like that.
The thing that annoys me is when windows steal focus. For example, I could be running an installer for some program. While it's working, I'll switch to my browser and browse, maybe entering some text into an email in my browser. Then suddenly the installer finishes and its window steals the focus. Now I'm in the middle of writing an email, so I might press a key that happens to be bound to a button on that installer, and then that button gets invoked, doing some action that I never intended to happen!
This is doubly annoying to me because I'm using a multiple-desktop program called DexPot, and when a window steals focus, it also brings itself to the desktop I'm currently on, which can be really annoying, because then I have to put it back into its original desktop.
How my ideal solution to this problem would work: Every time a window tries to steal focus, we intercept that, and don't let it. We show something like a toaster message saying "Foobar installer wants focus, press Win-Whatever to switch to it". If and when you press the key combo, it switches to the window.
The question is: Is there an easy way to tweak Windows to make this happen? I know very little about Windows programming. I do know AHK and if it's possible with that, that'd be great.
No, there isn't an easy way to add this behavior, but Windows tries to do this automatically.
In theory apps shouldn't be able to steal the foreground while you're actively using another app. Unfortunatly there are some scenarios where Windows can't tell the difference between legitimate user actions that should change the foreground and unwanted foreground-theft. The window manager generally tightens up the holes a bit with each new version of Windows, but also needs to make sure that apps can come to the foreground when the user wants them to, even if that desire is expressed indirectly.
For example, a process launched by the current foreground process can put a window into the foreground. This is necessary so that when a user launches a window from Explorer the newly launched process can open its main window. This permission only lasts until the next user input, so if an application is slow to launch and you start working on an email the app may lose its foreground permissions before it can use them.
See the SetForegroundWindow function documentation for a list of requirements for a process to be able to set a window into the foreground.
There are also apps which specifically make use of these requirements to steal the permission (by joining the foreground queue or synthsising user input to themselves), but I suspect in your installer scenario it is accidental.
I'm not sure what exactly is going on, but I suspect that the problem comes from the installer running as a service and accidentally stealing the foreground permission when it tries to launch the app on your current desktop.
It would be theoretically possible for an external process to hook into the foreground system to override this and show your confirmation toast, but it would be tricky to get right and would require significant low level code (I'd probably start with a CbtHook). It would not be possible in a scripting package like AHK (assuming you mean AutoHotKey) but would need to be native C/C++ code injected into every running process.
I am implementing a Cocoa application which supports the fullscreen mode. If the user quits while working on the fullscreen mode, I need to start the application in fullscreen mode,
While starting the application I check whether the application should start in fullscreen mode then call the toggleFullScreen: on NSWindow. Then the, application goes to the fullscreen mode and comes back to the normal window mode.
User can go to the full screen mode while working without any problem. Any tips on what's going wrong on this?
Make sure you really want to do this. Since Lion, there is a window restoration API that you should be using. See Any NSWindowRestoration examples? for how to use it. The caveat is that if "Close windows when quitting an application" in System Preferences is checked (which it is checked by default since 10.8), the window can only be restored upon reboot if the user chooses to do so.
If the user did not opt in for the window restoration setting throughout the OS across quitting applications, then generally you do not have to expect the window of your app to be restored for them. However, if you think you have a good reason otherwise, then I suggest invoking toggleFullScreen: after windowDidLoad: is called. I can only guess that you're calling it too soon and the window autosave might get in the way. It'd be helpful if you showed the relevant code.
Regardless, you should be implementing window restoration anyway and in the case of the window being restored by the API, you simply don't do anything.
I don't really know where to begin. Let's start with the stupid questions:
What language should I use for this? What is suited for the task at hand?
Next, the real ones:
Is there a way to stop the screensaver from starting, short of changing the cursor position? If not, will changing the cursor position even work?
SetThreadExecutionState will prevent the screensaver from coming on or the machine from automatically going to sleep if you pass the ES_CONTINUOUS and ES_DISPLAY_REQUIRED flags.
I wrote an app awhile ago that does exactly what you are asking for. It runs as an icon in the System Tray, not the Taskbar, and uses a global message hook to disable the WM_SYSCOMMAND/SC_SCREENSAVE notification from reaching any applications. If that notification does not reach the DefWindowProc() function, the screen saver will never run.
Your program does not need to be visible in the task bar at all.
You don't even need a program at all, if you can disable the screensaver in the registry.
What you want to do can perhaps be achieved by sending a MOUSE_MOVE event to the desktop window. If you want to use C# (the only language I am current with right now), you can look at this article, but maybe a simple C program using the WinAPI is better suited for this task.
.NET will easily allow you to put an application in the system tray (checkout the NotifyIcon object in System.Windows.Forms.Controls).
I believe you can use the SetCursorPos (http://msdn.microsoft.com/en-us/library/ms648394(VS.85).aspx) API call to prevent the screen saver, just make sure you set them to the current location so you don't actually move the mouse.