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.
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...
I have developed a full-screen application that hooks into and launched by a 3rd party/client application. The problem is that the client application gets focus soon after it launches my application, with the result that although my application is full screen, and set to be on top, it does not receive keyboard input, as such the user has to click on it to bring it to focus, which makes for a poor user experience.
How can I restore focus to my application after the client acquires it?
If it matters, my application is written in C++ and has a QT UI.
Not quite the answer but the reason why my application does not have input focus. I'll let Charles Petzold explain (from Programming Windows 5ed, pg 213)
The Window that receives a particular keyboard event is the window that has input focus. The concept of input focus is closely related to the concept of the active window. The window with the input focus is either the active window or a descendant window of the active window -- that is , a child of the active window, or a child of a child of the active window, and so forth.
My Qt application is not spawned spawned by an active window and therefore does not have input focus. The solution therefore would be to parent my application to the active window. Unfortunately this is not straightforward in Qt, if at all possible.
Here is the Qt documentation:
http://doc.qt.io/qt-4.8/qwidget.html#activateWindow
http://doc.qt.io/qt-4.8/qwidget.html#raise
http://doc.qt.io/qt-4.8/qwidget.html#setFocus
Hope it helps when called after launch...
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 am working on a utility application that controls other running applications. On certain input event my application displays a window, user can pick some operation from the window, the window disappears and control returns to the previous app. My problem is that clicking in my app’s window activates my application, thus removing focus from the previous application’s window. I can re-activate the previous application when my window closes, but I’d rather keep the original application activated all the time. Is that possible?
It's quite easy to to, just make your window an instance of NSPanel (a subclass of NSWindow), and set it as non-activating in Xcode/IB (or create it programatically, with NSNonactivatingPanelMask in the style mask).
One idea would be: while your app is running, try to keept track of the active window in the system.
After you activate your app and click the command button, restore the previous active window.
This is only an idea, I don't know how to do it on mac.
I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.