In an application I'm working on, I have a notification window that pops up to inform the users about events. It's very similar to the new mail notification used by Outlook--it shows up for a few seconds and then goes away automatically. But, if the mouse is on top of the notification window, the window stays visible until the mouse leave the window area.
To see if the mouse is within the window, I'm using the GetCursorPos and GetWindowRect Win32 API functions. These work great in most cases. But, I've discovered that they don't work as expected when I'm using the Unity mode of VMWare (where the application windows in the VM are made to appear outside of the VM). If the mouse is not within the area of the VM application, and is instead in an application running outside the VM, those Win32 API calls are still telling me that the mouse is in the VM.
As an example, when I'm running in Unity and the mouse is over my notification window, I get the following information from those two API calls:
Window Rect:
Left: 1190
Right: 1540
Top: 743
Bottom: 864
Mouse:
X: 1529
Y: 802
When the mouse is sitting over the Windows desktop or another non-VM application window, I get these results:
Window Rect:
Left: 1200
Right: 1550
Top: 748
Bottom: 869
Mouse:
X: 1547
Y: 799
As you can see, GetCursorPos is returning a mouse location that is within the screen rect of the window, so the notification never disappears, even though the mouse is not over it.
I've tried using the GetCursorInfo API to see if the cursor is showing, but that is returning a value of 1 in the flags variable in both cases. So, I'm at a loss of how to get this to work in Unity mode. Are there any other things I could check to detect this?
Related
I have a normal window, and I want to add a button, which can be pressed in my window when it's inactive, and this won't steal the focus from the currently active window.
Example: Touch keyboard button in the system taskbar of Windows 8/8.1/10, this one:
Please note an active application is still active when this button is clicked, but the focus goes to the taskbar when its empty space is clicked.
Classic solutions:
To make a whole top-level window non-activatable, WS_EX_NOACTIVATE ex-style can be used. Unfortunately, this style causes a lot of problems with top-level windows, and it cannot be applied to child windows.
Commonly recommended approach is to listen to WM_MOUSEACTIVATE message and answer MA_NOACTIVATE in case the control was clicked. This works, but only partially: The window won't be activated during the clicks, but the previously active window loses the active state, and GetForegroundWindow returns 0. This can be solved by remembering the last active window (either by periodical polling, or by monitoring EVENT_SYSTEM_FOREGROUND or HSHELL_WINDOWACTIVATED / HSHELL_RUDEAPPACTIVATED), and by forcibly restoring it. A lot of headache actually.
Win7-way:
Since Windows 7, there's a new undocumented API-function SetChildWindowNoActivate, with ordinal 2005 in user32.dll. It can be declared like this (Delphi-style):
function SetChildWindowNoActivate(ChildWnd: HWND): BOOL; stdcall;
external 'user32.dll' index 2005;
This function is used in Windows 8/8.1/10 to make no-activate buttons like Touch keyboard, Virtual touchpad and Language switcher.
Here's a screenshot of a sample application with a pushed no-activate button and an active Explorer window above it:
I do really need to make my window to stay on top on Windows, but Windows itself does not seem willing to allow me to do this.
I cannot use the workaround with setting registry values because I am not able to ask the user to log-out/log-in.
Besides, I use QML and the solution with QWidget::raise() and QApplication::setActiveWindow() does not seem to work also because I have not managed to get the QML root object as a QWidget pointer with the following code:
QWidget* mainWin = qobject_cast<QWidget*>(engine.rootObjects().at(0));
if (mainWin)
{
mainWin->raise();
QApplication::setActiveWindow(mainWin);
mainWin->activateWindow();
}
I have also tried to make the window active right from the QML:
window.raise()
window.requestActivate()
but with no luck also.
Is there, either way to bring the window on top on Windows without changing the registry and, preferably, from the QML purely?
Edit:
currently used window flags are:
Qt.Popup
Qt.FramelessWindowHint
Qt.WindowStaysOnTopHint
Qt.CustomizeWindowHint
Qt.BypassWindowManagerHint
Qt.MSWindowsFixedSizeDialogHint
I am deploying Qt 5.7 app on the Windows 10 x64 machine.
I have found this two bugfixes:
https://bugreports.qt.io/browse/QTBUG-14062
https://bugreports.qt.io/browse/QTBUG-37435
from which I can conclude that QWidget::activateWindow() and QWindow::requestActive() should work on Windows XP and Windows 7.
Here is my mcve, as #derM asked:
import QtQuick 2.7
import QtQuick.Window 2.2
Window {
flags: Qt.WindowStaysOnTopHint
width: 100
height: 100
visible: true
}
It was compiled under Windows 10 x64 with MinGW x32.
Easier way to reproduce: run in the command prompt
timeout 5 && debug\Test.exe
where debug\Test.exe is a path to the mcve binary, then open File Explorer and navigate somewhere. When the window opens, it won`t be in the foreground.
Harder way: If you just run it, the window will stay on top as it should.
But if you press Run button in the Qt Creator and switch the focus (I suppose, mouse focus should be changed, just pressing Alt+Tab won`t help) to another process (in my case - File Explorer), the window is displayed under the current active File Explorer window, and even if I will bring it up by clicking, it will go background as soon as I choose any other application.
The real application is started from a service, so there often will be an app holding mouse focus when my app is started. I suppose that Qt ability to bring the window to foreground is implemented using SetForegroundWindow API call, which notes the following restrictions in it`s remarks:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see - SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
So I wonder is it possible at all to bring the window to foreground if the process has been started by a service, not a user (i. e. the process has not been an active process during startup).
As you have posted: If the window is created from the foreground process, we will just make sure, that our process is the foreground process before we create the window.
import QtQuick 2.7
import QtQuick.Window 2.2
Item {
id: root
Component { // Like a splash screen: Claim to be foreground process,
// then create main window.
id: winInit
Window {
flags: Qt.WindowStaysOnTopHint
width: 1
height: 1
Component.onCompleted: {
requestActivate()
mainWin.createObject(root)
}
}
}
Component {
id: mainWin
Window {
flags: Qt.WindowStaysOnTopHint
width: 100
height: 100
visible: true
}
}
Component.onCompleted: {
var w1 = winInit.createObject(null)
w1.destroy()
}
}
I'm currently trying to keep the Windows Touch Keyboard (TabTip.exe) over a fullscreen Qt QML application.
Unfortunately, after showing (and forcing it to be on top) it's dismissed again.
It does not matter if I start the keyboard before starting the application or while running the application in fullscreen, after Qt is gaining focus, the keyboard is behind.
Any ideas what this could cause? Is this a Qt or Windows issue?
I found a way to keep the Windows keyboard above my QML "fullscreen" application. What I noticed is that in non fullscreen application, the keyboard appears well above my QML application. So the idea was to simulate a fullscreen application giving the window application nearly the size of the screen. Some code will be better:
ApplicationWindow {
id: mainWindow
x: 0
y: 0
width: Screen.width
height: Screen.height + 1 //+1 because does not work if the window size is equal to screen resolution. In some way, it considers it's a real fullscreen application and the keyboard stays behind.
flags: Qt.FramelessWindowHint | Qt.Window //first flag to remove top right buttons such as close button, second flag to keep the application thumbnail in the Windows taskbar to close it if necessary.
visible: true
...
}
With that, I can open the Windowd keyboard clicking on a text field, close it, re open it, ... all that I want!
I'm using QML to build an OSX application with fullscreen mode support. My intention is to toggle fullscreen/normal mode by double-clicking the main area of the window, here is the minimal code:
import QtQuick 2.4
import QtQuick.Window 2.2
Window {
id: main
visible: true
width: 800; height: 480
flags: Qt.Window | Qt.WindowFullscreenButtonHint // for OSX native behavior support
MouseArea {
anchors.fill: parent
onDoubleClicked: {
if (main.visibility === Window.FullScreen) {
main.visibility = Window.AutomaticVisibility;
} else {
main.visibility = Window.FullScreen;
}
}
}
}
It's very simple, but the behavior is weird:
Whenever the visibility state of the application changes(enter or leave), the user must click in the window one more time before the window mode can change again, just like the application loses the mouse focus.
To validate what I'm thinking, I test something more, I add one more MouseArea(let's say mouseAreaTest) in the window, which split the window side by side and can receive onEntered and onExited event. Right after the application enter or exit fullscreen mode, mouseAreaTest will never receive any Enter or Exit event, unless you click on the window one more time, which is not what I want.
I know nothing about how OSX implement its own fullscreen mode, nor why QML on OSX has such a buggy problem. So I expect someone will tell me something about it.
Update
Later I doubted if this was only something about QML which related something about the Window System of QML, so I tried using traditional QtWidgets, and found the same result there.
Update
I tracked the mouse event of traditional widget, and found the problem: the double click event consisted of two click event(press-release-press-release), when the window state changd(fullscreen to normal or normal to fullscreen), the last RELEASE event will never be received UNLESS click one more time.
I also did more test: use a button to control window state, and the problem is gone, so I may probably consider this is a bug of mouse event handle.
By the way, post system info for a note:
OSX 10.10.1
Qt 5.4.1
This bug still exists in Qt 5.11. I found a workaround eventually.
The reason why the last mouse release event not received is that we toggled fullscreen immediately. Somehow the mouse release event was lost during transition to fullscreen.
So the fix was simple: we postpone toggling fullscreen till next mouse release event. i.e. when we need to toggle fullscreen, set a flag temporarily, then in mouseReleaseEvent, check the flag and do the real work.
I am trying to mimic a Head-Up Display in a racing simulator, and I want to display a semi-transperant program window (i.e. a browser window showing a java applet) which limits mouse movements to that window only.
That way I can use a USB-track pad or the like to interact with the content in the dialog screen while still interacting with the racing simulator.
My question is mainly focused on the restriction of mouse movement, is this possible in Windows 7?
Regards
Use the ClipCursor API call - Make sure you undo any clipping when your window is deactivated or minimized.