How do I determine if a window is off-screen?

Question

In Windows XP and above, given a window handle (HWND), how can I tell if the window position and size leaves the window irretrievably off screen? For example, if the title bar is available to the cursor, then the window can be dragged back on screen. I need to discover if the window is in fact visible or at least available to the user. I guess I also need to know how to detect and respond to resolution changes and how to deal with multiple monitors. This seems like a fairly big deal. I'm using C++ and the regular SDK, so please limit your answers to that platform rather than invoking C# or similar.

Ellon

Answer 1

Windows makes it relatively simple to determine the size of a user's working area on the primary monitor (i.e., the area of the screen not obscured by the taskbar). Call the SystemParametersInfo function and specify the SPI_GETWORKAREA flag for the first parameter (uiAction). The pvParam parameter should point to a RECT structure that will receive the coordinates of the working area in virtual screen coordinates.

Once you've got the coordinates that describe the working area, it's a simple matter of comparing those to the current position of your application's window to determine if it lies within those bounds.

The desire to support multiple monitors makes things slightly more complicated. The documentation for SystemParametersInfo suggests that you need to call the GetMonitorInfo function instead to get the working area of a monitor other than the primary. It fills in a structure called MONITORINFOEX that contains the member rcWork that defines the working area of that monitor, again expressed in virtual screen coordinates as a RECT structure.

To do this right, you'll need to enumerate all of the monitors a user has connected to the system and retrieve the working area of each using GetMonitorInfo.

There are a few samples of this to be found around the Internet:

• MSDN has some sample code for Positioning Objects on a Multiple Display Setup.
• If you're using MFC, here's what looks to be an excellent example of multiple monitor support.
• Even if you're not using MFC, that article refers the following link which looks be a real gem as far as explaining how multiple monitor supports works in Windows, even if it's a little bit old school. Like it or not, very little of this has changed in later versions of Windows.

Finally, you mentioned wanting to detect resolution changes. This is much simpler than you probably imagined. As you know if you've done any Windows programming, the primary way that the operating system communicates with your application is by sending messages to your WindowProc function.
In this case, you'll want to watch for the WM_DISPLAYCHANGE message, which is sent to all windows when the display resolution has changed. The wParam contains the new image depth in bits per pixel; the low-order word of the lParam specifies the horizontal resolution and the high-order word of the lParam specifies the vertical resolution of the screen.

Manchukuo

Thanks, that's an excellent start - I can't believe I've not come across SystemParametersInfo before. I'm still stuck with the problem of whether or not the title bar is visible though, and what happens if the resolution changes. – Ellon

@hatcat: No reason to beat yourself up; the Windows API is big and no one knows everything. I'm not sure how you could still be stuck on the title bar's visibility. Check to see if the region of your window containing the title bar lies within the working area of the screen that you got using either of the functions described above. And I straight forgot about detecting resolution changes; I'll update my answer. – Manchukuo

Thank you! I've been programming Windows since 1992, believe it or not. I think the hardest thing is knowing what functionality has been superseded, and when, and whether or not you should stick with what you know. The title bar part was more to do with retrieving that region so I could test it. I'm just going to check the top ten pixels and the side ten pixels, that should be enough. – Ellon

@hatcat: Ah, I wouldn't hard-code a value of 10 pixels; it's too easy for that to break. Especially when you can determine the actual size using the GetSystemMetrics function. To get the height of a window's title bar in pixels, specify SM_CYCAPTION for the nIndex parameter. To get the width of a window border in pixels, specify SM_CXBORDER, and for the height of a window border in pixels, specify SM_CYBORDER. – Manchukuo

D'Oh! Yes, I remember that now. Blimey, the grey matter is shrinking. Thanks again. – Ellon

Answer 2

You can use MonitorFromRect or MonitorFromPoint to check if window's top left point or bottom right point isn't contained within any display monitor (off screen).

POINT p;
p.x = x;
p.y = y;
HMONITOR hMon = MonitorFromPoint(p, MONITOR_DEFAULTTONULL);
if (hMon == NULL) {
    // point is off screen
}

Margret

Add some description – Manson

I use this as working solution to check if window is off screen. It's simpler than original answer. – Margret

Nice, this is simpler that enumerating all the monitors. To thoroughly answer the original question, you should use MonitorFromRect using a RECT that represents the title bar. – Sinusoidal

Answer 3

Visibility check is really easy.

RECT rtDesktop, rtView;

GetWindowRect( GetDesktopWindow(), &rtDesktop );
GetWindowRect( m_hWnd, &rtView );

HRGN rgn = CreateRectRgn( rtDesktop.left, rtDesktop.top, rtDesktop.right, rtDesktop.bottom );

BOOL viewIsVisible = RectInRegion( rgn, &rtView );

DeleteObject(rgn);

You don't have to use RectInRegion, I used for shorten code.

Display, resolution change monitoring is also easy if you handle WM_SETTINGCHANGE message.

http://msdn.microsoft.com/en-us/library/ms725497(v=vs.85).aspx

UPDATE

As @Cody Gray noted, I think WM_DISPLAYCHANGE is more appropriate than WM_SETTINGCHANGE. But MFC 9.0 library make use of WM_SETTINGCHANGE.

Roadhouse