There is GetRandomRgn( hdc, hrgn, SYSRGN ) to determine window's system clipping region.
When my window is partially covered by other windows I get the correct region.
However, if window that covers my window is a tooltip, it's not subtracted from the region returned by the function.
Any idea why tooltip windows are not excluded and what can I do to exclude them without enumerating all windows myself, determining how they affect my window, etc?
Thank you.
Update: this is on Windows 7 with Aero disabled.
Because tooltips are layered windows. Layered windows do not participate in classical occlusion. (One reason is that they have alpha, so occlusion is not a binary concept.) You didn't say why you need this information so there's not much more that can be said beyond "yup."
Related
When a window is resized by aero snap, User32.GetWindowPlacement(hWnd).rcNormalPosition still stores its original rectangle, while User32.GetWindowRect is affected.
Since aero snap seems independent from WINDOWPLACEMENT, now we cannot collect the complete information of the actual placement simply using user32.dll. Thus I'm wondering if there's a way to get the aero snap state of a window, indicating whether the window is docked and which side the window is docked to.
Aero Snap is a feature of the Shell, not the windowing system. Thus, the windowing system cannot provide that information, because it is not aware of those states.
And the Shell doesn't make this information available either. So, in essence, the system doesn't provide the Aero Snap state of any given window through a public API.
I like having my main windows remember all of their placement information so that I it can be restored when they are restarted. In that past, it was enough to save a copy of the window placement structure and to set it back when recreating the window.
The introduction of snap required keeping some extra information. I detected whether a window appeared to be snapped by comparing its window rectangle to the work area rectangle of the monitor that contains the window. If it seemed to be snapped to one of the edges, I recorded that along with the placement information. Upon creating the window, I first restore the window placement, and then, if I have a snap state recorded, I change the window's size and position accordingly.
You can distinguish between a window that's been snapped to a monitor edge from one that's been carefully sized and placed there because the snapped window's rectangle won't match the one in the window placement.
This approach worked great in Windows 7. I recently discovered that Windows 10 added more flexibility to the snap locations and sizes as well as playing more games to achieve the annoyingly invisible resize borders. So my detection code doesn't always recognize a snapped window, but that should fixable.
Some popular software (like the major browsers) seem to remember that they were snapped, and I assume they use the same approach.
I noticed that the focus rectangle has changed in one of our legacy app when it works in Windows 10. It turned out that there are other old-style Microsoft apps in which we see the same effect - for example, in HTML Help Workshop. The focus rectangle must be a dotted rectangle consisting of alternating black and white dots, but we see a 2-pixel rectangle blended with the selection that looks like a red-orange rectangle:
The problem appears only on 2 computers with Windows 10, version 1909. One of them is the Pro edition, the other is the Home edition.
The focus rectangle is drawn in our app with the WinAPI DrawFocusRect function. The documentation for the DrawFocusRect function states the following:
Windows XP: The focus rectangle can now be thicker than 1 pixel, so it
is more visible for high-resolution, high-density displays and
accessibility needs.
But this does not help to understand why the problem occurs only on those 2 computers. They are equipped with normal 96dpi displays, and as I know, no accessibility options are turned on in them.
What it could be and how to fix the drawing of focus rectangle to see the traditional 1-pixel black/white dotted rectangle?
If it helps, here is an example of code used to draw the focus rectangle in our VB6 app:
Dim hBrBlack As Long
hBrBlack = CreateSolidBrush(vbBlack)
FrameRect hMemDC, rcFocusRect, hBrBlack
DeleteObject hBrBlack
SetBkColor hMemDC, lColor1
SetTextColor hMemDC, lColor2
DrawFocusRect hMemDC, rcFocusRect
Thank you all who commented my question. The situation became clear, but not in all parts of the problem. I am resuming all what we know by now in this kind of an answer.
Yes, indeed, in Windows 10 we can open Control Panel > Ease of Access > Ease of Access Center > Make the computer easier to see and find the Make the focus rectangle thicker option:
The first thing I do not understand is that why this option became checked. Simon Mourier thinks it is a carryover from a previous Windows installation, but I doubt this is true. I definitely know that at least on my dev pc nobody checked this as only me could do that. It seems that Windows decide at some point to check this option itself depending on some system parameters.
The second incomprehensible point is why the focus rectangle became dark-orange-red. But maybe, this is by design. Perhaps, somebody in Microsoft decided that this color is the best choice for the focus rectangle.
Taking into account all this, I think, the best choice for me and other developers who need the focus rectangle in our apps is to draw the focus rectangle by ourselves using the thickness defined by the SPI_GETFOCUSBORDERHEIGHT and SPI_GETFOCUSBORDERWIDTH system parameter values.
I am looking to create a custom rounded frame for an application window (border-radius and shadow)
From a performance point of view, what would be the best technique for this?
a. Use regions (SetWindowRgn) for the rounded application window and a layered window (UpdateLayeredWindow) for the shadow.
b. Use layered windows for both the rounded application window and the shadow.
The docs for UpdateLayeredWindow specify:
For best drawing performance by the layered window and any underlying
windows, the layered window should be as small as possible.
I am asking this specifically for the application main window, so a large window that can have a high complexity and is most of the times visible on the screen.
Should I go with regions or layered window for the application window? Which one would be lighter on the CPU/memory?
SetWindowRgn disables DWM for the given Window. DWM ist the component that is responsible for performantly drawing the Window frame using the available graphics hardware. That should pretty much rule out SetWindowRgn. Also, SetWindowRgn produces very "ancient" looking results because antialiasing is not possible. A pixel can be either fully transparent or fully opaque.
For best drawing performance by the layered window and any underlying
windows, the layered window should be as small as possible.
I believe that in 2018, this hint is less relevant. The documentation was written 18 years ago when the hardware was way more limited than today.
Still, UpdateLayeredWindow is not the fastest way to draw custom window frames, especially when you have to update the bitmap often (e. g. during window resize). The bottleneck is that these updates have to go from system memory to graphics memory. To minimize window size, create four small windows which are only large enough to draw the borders/corners of your window. This trick is pulled by Visual Studio for instance. Using Spy++ one can see 4 instances of "VisualStudioGlowWindow" which are layered windows that are just 9 pixels wide/tall (on my system):
If you want maximum performance, you may also look into Direct Composition, combined with the WS_EX_NOREDIRECTIONBITMAP extended window style, as explained in the article "High-Performance Window Layering Using the Windows Composition Engine". This technique requires Windows 8 at least.
I am trying to get the width and height of all the windows. I did this easily with GetWindowRect however the styling in Win8.1+ seems such that there is a border on some windows and thats not being included. When I move/drag the window, this area moves with the window, so I expected it would be apart of its geometry. Is this known? Is there away to include the border width?
New Example
I created a second screenshot to explain after I see some confusion in the comments.
I have two windows side by side as seen in this image here:
Now if I take the GetWindowRect of the left and right windows, it should be a continuous rectangle around both of thse windows. However in the below we see this is not the case. I put a black fade over the whole desktop and cut out just the parts of the GetWindowRect for each window, we see the left window GetWindowRect is a bit smaller, this is my problem.
Old Example
For example this is a screenshot, using the cleared/non-black curtain area is what GetWindowRect identified as the width height, x and y:
We see there is some area of the window not included, I think this is the border? I used photoshop here to put a blue border around what all should have been:
And just for clarity I put an inner red border to show that the area between the red and blue borders was what should have been included, but was not:
Does anyone know how to include this "border" in the GetWindowRect?
Yes, GetWindowRect() lies to you. As you found out. It is a necessary lie. Goes back to Vista, the first Windows version that gave resizable windows their fat border. A pretty necessary feature, high screen resolutions were getting pretty common and the traditional 2-pixel border was getting too hard to hit with a mouse.
That created a massive compatibility problem however, many programs that create a window use CreateWindowEx(), you specify the outer window size. And don't use AdjustWindowRectEx(), the function that you must use to calculate the window size you need. Necessary because almost every window actually cares about the client size of the window. The part you fill with content. If they would have done nothing then legacy programs would end up creating windows with a client area that is too small, no longer fitting the content or aligning it out of whack. Very, very ugly.
So GetWindowRect() lies and pretends that the window has the traditional 2-pixel border. Pretty consistent lie, if you ask for the border size with GetSystemMetrics() then you get 2 back, even though it is 5. All works pretty well, until you start caring about positioning windows next to each other. Impossible to lie about that.
Turning off the lies requires letting Windows know that you are aware of the consequences of the fat borders. And know how to deal with Aero being turned off, possible on Vista and Win7. You must select the sub-system version number in the EXE file header and pick at least 6.00. The vast majority of programs use the legacy value, 4.00. Exactly how that's done depends on your tooling, for the Microsoft linker it is the /SUBSYSTEM option. It can be changed after the program was built with Editbin.exe, /SUBSYSTEM option. The program will no longer run on XP and earlier.
Windows 10 took an interesting new approach to this problem. The skinny borders are back. But now with a much bigger drop-shadow, the mouse is active beyond the border, even for windows that don't have a shadow. Works pretty well, hopefully we can all forget about this appcompat detail soon :)
In Windows 7, we have the glass-like windows where parts of other windows or the desktop shines through:
Somewhere, Windows must know which regions are translucent in order to render the window correctly.
Many test automation tools have the ability to use bitmaps for comparing expected results and the translucent parts of windows can cause problems.
I wonder whether it is possible to detect the translucent regions of a window programmatically, e.g. by an API call, in order to implement a screen comparison tool that is robust against glassy windows.
The usual workaround is to disable Aero, but even then, the window color can depend on other system settings which need to be considered. Detecting the transparent regions could be even more reliable than detecting control panel appearence colors.
Also, since we have semi-automated tests, I'd turn off Aero for a short time only and turn it back on when the automated part of the test is finished. This causes unwanted flickering.
Note that I don't want to detect transparent regions in already captured images as discussed in Detecting transparent glass in images. I'd like to do it at a time where the OS can still distinguish transparency.