This question might show a fundamental misunderstanding of DirectX programming in Windows, but I'm having a bit of an issue I can't figure out. My program, when running in full screen, sometimes gets in a weird state and I have to force close the app (CTRL+ALT+DEL).
The problem is that when I hit CTRL+ALT+DEL, task manager appears, but I can't use the mouse; the keyboard works at first, but if I click on the Task Manager window with my mouse, it loses focus and I can no longer regain focus. The app also does not minimize itself (Windows app programming issue?)
Is it possible that my app is stealing the exclusive possession of the mouse? I am using DirectInput, but the mouse input is not handled by the app at all. Furthermore, this problem only happens when running the app fullscreen. If I run it in a Window, everything is fine.
If it matters, the tools I'm using are MS Visual Studio 12, Windows 8, and DirectX 9.
The solution to this was to unacquire all input devices and stop the rendering routines when the focus was lost from the application.
I just set the app to keep track of whether or not it has focus, and to adjust the value appropriately in the Windows message pump for the appropriate messages. Specifically, I set focus to "off" when I receive the following messages:
WM_SIZE (when wParam = SIZE_MINIMIZED), WM_KILLFOCUS, WM_ENTERSIZEMOVE, and WM_ENTERMENULOOP
I set focus back on for the following messages:
WM_SIZE (all other cases), WM_SETFOCUS, WM_EXITSIZEMOVE, WM_ACTIVATEAPP with wParam set to true, and WM_EXITMENULOOP
WM_KILLFOCUS is adequate to solve the problem for ALT-CTRL-DELETE-ing out of the application.
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...
WM_MOUSEMOVE is sent when the mouse is moved over my window, regardless of whether a mouse button is held down or not.
However, the above is not true if the user is in the process of carrying a file into my window.
How can I get notified of this special case?
I'm ok with requiring a minimum of Windows 7, or even Windows 10.
I found this question which is almost the same, but I can't implement the IDropTarget COM interface, because my project has not been created as an "ATL COM" app nor as an "MFC application that contains ATL support".
Edit: I'll try WH_MOUSE_LL from the above-linked question.
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 have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.
This question is more academic than practical and doesn't involve any one specific language. For the sake of discussion, we'll use Win32 API.
What is the most appropriate way to create a window with the following behavior goals:
Z-Order is lower than every other window except the desktop surface.
Cannot be made to appear on a higher z-order than other windows through mouse or keyboard clicks.
Assumption may be made that the window is borderless.
There are two basic approaches here :-
make your window the 'child' of the desktop.
make your window simply refuse to accept focus or activation :-
The wonder of the windows window manager is that there isn't one. Rather, there is an appearance of a window manager as a result of the emergent behavior of all the windows in the system - namely how they react to messages - which in 99% of cases is handeld by DefWindowProc.
Which means that you can subvert a lot of normal window manager type behaviour by handling messages before DefWindowProc. If you create a window, and position it using the relevent flags at the bottom of the z-order with SetWindowPos, and then handle messages like WM_WINDOWPOSCHANGING, you can ensure that your window never receives activation or focus and always - even when other apps call SetWindowPos - always has the z-bottom flag set.
both approaches are problematic as its very difficult to find out what the desktop window is. GetDesktopWindow returns a handle to a window that is only ever visible if explorer crashes. The rest of the time, the visible desktop is a window created by explorer - ultimately a syslistview control. Spy++ + Findwindow will get you a handle to the window you want to be above.