I am writing a virtual desktop application which utilises the DeferWindowPos API functions. The current method I am using is moving the windows off the screen if they're not on the current virtual desktop. However I know wish to also hide the windows that are off-screen so they do not appear on the task bar. I have attempted this by also passing SWP_SHOWWINDOW/SWP_HIDEWINDOW to the DeferWindowPos() calls. I have read a few sites regarding this and one of them suggested that if SWP_SHOWWINDOW/SWP_HIDEWINDOW are passed, then the window will only show or hide, and no reposition. Can anyone confirm this, or am I doing something wrong?
In addition to the rtfm, DeferWindowPos is eventually going to call SetWindowPos. SetWindowPos always validates its parameters by passing them to the WindowProc via WM_WINDOWPOSCHANGING so, unless you are also hooking every windows WindowProc as part of your virtual desktop manager, moving them off screen is going to fail for any windows where the devs are doing something "clever" or unusual - like clamping to the edge of the workspace.
You need to read the documentation, which clearly states
If any of the windows in the multiple-window- position structure have the SWP_HIDEWINDOW or SWP_SHOWWINDOW flag set, none of the windows are repositioned.
I, too, noticed this statement in the documentation:
If any of the windows in the multiple-window- position structure have the SWP_HIDEWINDOW or SWP_SHOWWINDOW flag set, none of the windows are repositioned.
...after I'd already rewritten some code to use DWP, so I thought I'd try running it. It worked just fine even though I'd used either SWP_SHOWWINDOW or SWP_HIDEWINDOW for every single call to DWP.
This was on Windows 7 64-bit, so YMMV.
Related
I found a bug yesterday in one of my Windows applications, which is built in a high level framework, which in the end, calls Windows APIs like CreateWindow, and ShowWindow, in order to display its user interface.
One one machine so far, and only one, which happened to be a customer machine, I observed the following behaviour:
For only one window in my entire application, when I first call ShowWindow(Handle,SW_SHOW ) for this window, the size which it previously had received by SetWindowPos is overridden.
Reading the MSDN Win32 API documentation, on ShowWindow(Handle,SW_SHOW) I can not see any reference it it moving the window bounds. I can work around this surprising result by having my window-show routine get the bounds before it calls the Win32 ShowWindow routine.
My question is, has anyone ever seen behaviour like this? I think it must be one of the following:
An obscure bug in Windows 7 Service Pack 1 that does not reproduce on all systems, and only reproduces perhaps for a particular version of a particular video card driver. (This affected system has dual AMD/ATI FireGL video cards)
An obscure problem caused by a side effect of some other software running on the system, which may be hooking window handles, installing trampolined code hooks somewhere (perhaps even inside my own process, thanks to some DLL or something that I am not aware of).
Something my 4 million line application is doing to me, through some weird code somewhere I have not yet identified.
I am hitting an application compatibility shim within the Win32 API layer.
If anyone who has worked in C++, C, or Delphi, or any other language, has ever seen anything like this and can think of a reason why ShowWindow would have this amazing and unexpected side effect, of moving the bounds of the window, back to a certain original position, in my case, x=175, y=175, width=320, height=240, which appears to be have been the window bounds right after the initial CreateWindow call, I'd like to know what it is.
Here is a sequence of events:
Application starts up, and creates a few top level windows parented to the desktop.
The first window created is the main application window and the second is a tool window, both have full window grabber bars and are conventional top level Win32 windows, Forms which are sizeable, draggable, and parented to the desktop.
The second window's position is loaded from disk, and the form is shown.
During the form show process, its bounds are set so that the window is at some x and y top/left position, and some height/width is given.
If I query the Win32 window handle immediately before I call ShowWindow, its bounds are where I expect.
If I query the Win32 window handle immediately after I call ShowWindow, its bounds have been reset.
According to MSDN help SW_SHOW means Activates the window and displays it in its current size and position.
This is indeed what occurs on over 100 client PCs I have observed. Only on a single customer-owned Windows 7 PC is this behaviour different.
This affected system has dual AMD/ATI FireGL video cards
I ain't sure about FireGL, but for consumers videocards, made upon the same chip lineage, video-drivers exactly have add-on to reposition windows as they think is easier for operator.
it is called HydraVision Package for Catalyst Software Suite
I have ListView which items are completely drawn using my code. Of course I use data provided by NMLVCUSTOMDRAW primarily RECTs. There are two rects p->nmcd.rc and p->rcText, first one carries valid information and the other one is always 0. This issue is that nmcd.rc does not contain valid rect on Windows XP I get 0,1,0,2 or something like that.
As that did not work I tried using ListView_GetItemIndexRect which fails on Win XP, while it works on Win 7/10.
Looking at the ListView_GetItemIndexRect's msdn page I can see that apparently it works only on Vista+. While at the same time some other ListView functions that are listed as Vista+ work fine on Windows XP.
Windows XP is rare among my program's users, but still I'd like it to function perfectly. Drawing complete list view on my own would fix the problem for sure, but that is a dead end.
Check out the first comment on this page:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774778%28v=vs.85%29.aspx
Handling subitem pre-paint messages on Windows XP (perhaps all
pre-Vista systems?) the handler receives incorrect top and bottom
values in NMLVCUSTOMDRAW::nmcd.rc, sometimes they are zero, sometimes
are not updated since previous handler call (so basically the idea is
that they are left uninitialized by comctl32 caller). In order to get
correct subitem position the handler has to explicitly obtain
rectangle using a separate message/call:
RECT Position; ListView.GetSubItemRect((INT) pHeader->nmcd.dwItemSpec,
pHeader->iSubItem, LVIR_BOUNDS, &Position);
The title pretty much says it all. I've created a window with namedWindow() and filled it with a matrix. I then assign it to a HWND using cvGetWindowHandle() so that I can use the Windows function SetWindowPos(). Using this I'm supposed to be able to set the flags HWND_TOPMOST, SWP_NOMOVE and SWP_NOSIZE in order to keep it above all other windows even when I click on a window behind it.
I've either misread something here and got the wrong idea or I believe that the problem might be the fact that I have upgraded to Windows 8 and they have deprecated this function or something. Is there another way to go about this?
I don't have a setup to try this in c++, but I wanted to do something similar in python so I ended up using a python win32 library. With a combination of the following calls (I assume you can find them for win32 in c++), I always managed to get the screen on top. But it didn't stay there. I had to bring it up when I wanted it.
win32gui.SetForegroundWindow(hwnd) # I use just this. apparently it can trigger permission error but I never had a problem with it
win32gui.SetFocus(hwnd) # apparently doesn't trigger error without permission like setforegroundwindow
win32gui.BringWindowToTop(hwnd) # not sure if this helps any
win32gui.SetActiveWindow(hwnd) #not sure if this helps any
I am attempting to change the display settings to "Duplicate" when I have 2 monitors connected to a PC?
Ie, I am attempting to select the following setting(outlined in red) but using a WinAPI function call.
My Problem: I dont know what WinAPI function call I use to change the display setting to "Duplicate"? I've googled and haven't found any such function.
I am looking for a function that is supported on Windows 2000 or XP and up and not just a Windows Vista and up function. Does anyone know what WinAPI function call I use to achieve this?
I believe you want to use ChangeDisplaySettingsEx. You set up DEVMODE structures for both monitors, with the dmPosition member set to (0, 0), and set (only) the DM_POSITION flag, so all you do is change their relative positions, not things like resolution or bit depth.
This is supposed to work back as far as Windows 2000.
i THINK U WILL GET THE ANSWER OF YOU QUESTION LINK BELOW
http://www.c-sharpcorner.com/uploadfile/GemingLeader/changing-display-settings-programmatically/
I have a C++ app where I need to create topmost windows. Sometimes it works, but quite often it fails. In one part of the app, I create a background thread to display a topmost information window. After the user closes the window the thread goes away. The first time the app creates the thread and displays the window, the window is topmost. However, all subsequent threads fail to set topmost on their window. I have tried both creating the window with the WS_EX_TOPMOST style and by calling SetWindowPos after the window is created. Neither of these methods works. I looked and was unable to find any references to anyone having a problem where the window could not be set to topmost.
In one test that I ran, I called SetWindowPos and after it returned I checked the window's style and it was not set to topmost even though SetWindowPos returned success. I have also used Spy++ to check the window's style and it confirms that the style is not set.
One way SetWindowPos will silently fail to set WS_EX_TOPMOST is when the process doesn't have permission to SetForegroundWindow at the time window is created or SetWindowPos is called. Which is arguably one of the times you want the window topmost (and arguably one of the times you should not be allowed to).
Rumors are MS closed that loophole since Vista.
The restriction is understandable -- you don't want topmost windows from random processes stealing focus when they have no business too.
A workaround for a reasonable use case when one process indirectly launches a helper process (like would be a case of install initiated in parent process then helper process launched from msiexec) and helper then wants to be topmost or even grab input is to use AllowSetForegroundWindow.
You need to have the right to focus to be able to relinquish it, obviously.
I had a similar problem using Borland C++ Builder. I got this to work by setting the FormStyle to fsStayOnTop after the window was created and displayed. I think that the trick is to do this only after the window is fully displayed.
*visibleForm = new TForm3(Form3);
(*visibleForm)->FormStyle = fsStayOnTop;
SetWindowPos(_hYourWindow, HWND_TOPMOST, 0, 0, 0, 0,
SWP_ASYNCWINDOWPOS|SWP_NOSIZE|SWP_SHOWWINDOW|SWP_NOMOVE);
Should work!
No idea if the problem I had was the same as yours, but at least it had the same symptoms. Solved it by moving the this->TopMost = true from InitializeComponent to the Form_Load instead.
Why don't you just use SetForegroundWindow(). There's a lot less to go wrong..