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.
Related
ISSUE:
On a touch panel with no keyboard, my QT C++/QML app running on Windows 10 IOT has the fullscreen GUI "frozen", when the monitor turns on (after the user has triggered the touchscreen), after it has timed-out earlier and turned off due to power settings. Mouse cursor still updates.
The QML GUI has "flags: Qt.FramelessWindowHint | Qt.Window"; I do not want to add "Qt.WindowStaysOnTopHint" as it will block the control panel window when it is open from the app. The program is verified to be still running, only the GUI has frozen from the point in time when the screen turned off.
TEMPORARY RESOLUTION:
The only way to "unfreeze" the fullscreen GUI is to connect a keyboard & press the Windows key to show-hide the start menu, or do it programmatically with a manual QML button placed at a known position or on detection of monitor WM_POWERBROADCAST messages.
When the app is not fullscreen, the freezing doesn't seem to be happening.
Is this due to some missing WM_MESSAGES (e.g. WM_PAINT, WM_ACTIVATE, etc) sent by the OS to the app when it is fullscreen, or when the start menu button is pressed?
Can the app-fullscreen-freezing on monitor-turn-back-on be rectified by the app programmatically sending a sequence of WM_MESSAGES to itself, but not the Win button keypress (as the normal user is not supposed to access the OS or see anything related to the OS when the app is running)?
I tried using winAPI SetForegroundWindow() function...?
:-( Fast forward a few days...
With further testing, it seems that using SetForegroundWindow() alone is not consistent/reliable. Sometimes it works, sometimes it doesn't.
The most reliable that works 99.999% of the time is still the VK_LWIN keypress sent by the app. But, as mentioned before, the app user is not supposed to see the start-menu appearing then disappearing. Best if the behavior of the VK_LWIN keypress could be duplicated to the app without seeing the start-menu...
Good morning, in my application on MacOSX I want to give the user the option "minimize to tray". I use Qt5 and I rewrote the
changeEvent(QEvent *event)
function. There I do something like
switch( event->type() )
{
case QEvent::WindowStateChange:
{
if ( this->windowState() & Qt::WindowMinimized ) {
if( *option minimize to tray enable* ) {
event->ignore();
QTimer::singleShot(0, this, SLOT(hide()));
}
}
break;
}
default:
break;
}
Well, it works on Linux and Windows but the problem is that in MacOSX this code does not work properly and creates a bug. Indeed the window is still minimized in the taskbar (apart from the dock) and furthermore, if the window is resized from the taskbar instead of the tray icon, the GUI is blocked and does not change. The GUI can still send signals but it can not change. I have to reshow the window from the tray icon to unblock the GUI.
Then the question: How can I avoid to minimize the Window in the TaskBar on MacOSX?
Another related question: I have read some forum where some user speaks about a "standard behaviour" in MacOSX, as for example not to close the application when the "x" button is clicked, or not to use tray icon ecc. ecc.... Someone can post a official link how an application should behaves in MacOSX?
Thanks very much to everyone
Well, I don't know Qt, but I know Cocoa quite well. Speaking in terms of the Objective-C API, your hide() call is probably doing the equivalent of -orderOut:. Unfortunately, -orderOut: doesn't work properly for minimized windows. It leaves a "ghost" window in the Dock, which can be unminimized to an actual ghost window. That is, it's just an image of the window, it's not the actual live window.
It does work to call -close. I don't know what the Qt equivalent would be. You have to be careful to avoid some of the secondary consequences that -close has beyond those of -orderOut:, though. For example, some windows are set to release themselves on close, which you'd want to disable. Also, the window delegate's -windowWillClose: method will be called and it should do nothing for a not-really-closing call.
Don't worry that "closing" is more severe or permanent than "hiding" or "ordering out". It's really much the same thing, other than the above-mentioned additional consequences. For example, it is still possible to re-show a window that's been closed, etc.
The question is, does Qt give you the flexibility to do it. Alternatively, this can be considered a bug in Qt, that its hide() implementation uses -orderOut: rather than -close on minimized windows.
Finally, I'll ask if you really want to implement this feature. It's going to confuse users. When you minimize a window, it animates the minimization to the Dock. That gives the user a strong impression of where to find the window. If the window is not subsequently found where it went, the user is not going to know to look elsewhere. Likewise, Exposé/Mission Control shows users the minimized windows of an app in addition to the normal windows. Your supposedly minimized-to-tray windows won't show up there because they're no longer really minimized.
Perhaps just disable minimization. Have the user simply close the window when they're done with it and re-open it from your status item menu.
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.
If my wxWidgets application creates a new window while the application does not have focus, its taskbar icon blinks yellow until I switch to it, as shown here:
This is annoying. How can I prevent this from happening?
EDIT: The original version of this question suggested the blinking was happening during startup. After further investigation, this is not occurring right at application startup; rather, it occurs if I create an additional window while the application does not have focus.
To give a bit more background: my application is a sort of server, that opens windows in response to network events. If I boot up the application, then switch focus to something else and a network event comes in while the focus is elsewhere, my application will open a new window in the background (not grabbing focus) and this blinking will occur.
The windows are wxFrames; the application constructs them and their child widgets, then calls Show(true) on the frame.
Also, I've attempted to set a breakpoint on the FlashWindow Win32 API function, hoping to trap wherever in WX it's getting called, but haven't been able to make that work.
Maybe the following would work:
wxTopLevelWindow::ShowWithoutActivating ( )
http://docs.wxwidgets.org/trunk/classwx_top_level_window.html#a03e526f505716568318d601318527bd0
Yes. If you create a new top level window while the app does not have focus, then the task bar icon will flash. This is the intended behaviour of the windows operating system.
I want to observe any window on OSX if it is moved. I don't own the windows so i can't get to it directly so I think I have to use the Accessibility APIs. I found a solution for the current active Application here: How can my app detect a change to another app's window? but I can't figure out how I have to modify this that it works for any window which is open. I hope anybody could give me a hint in which direction I have to look.
As I mentioned in the comments, people usually only want to detect window-move events on focused windows. (As unfocused windows seldom move.) If you want to detect application switches, you can poke into this sample project by Apple that shows how to update iChat status with the frontmost application’s name. And as you said, there’s already a solution for an active window.