When obtaining the DPI for the screen under Windows (by using ::GetDeviceCaps) will the horizontal value always be the same as the vertical? For example:
HDC dc = ::GetDC(NULL);
const int xDPI = ::GetDeviceCaps(dc, LOGPIXELSX);
const int yDPI - ::GetDeviceCaps(dc, LOGPIXELSY);
assert(xDPI == yDPI);
::ReleaseDC(NULL, dc);
Are these values ever different?
It's possible for it to be different, but that generally only applies to printers. It can be safely assumed that the screen will always have identical horizontal and vertical DPIs.
I have never seen them be different, but on this MSDN page I see a comment that suggests that they might be:
int nHorz = dc.GetDeviceCaps(LOGPIXELSX);
int nVert = dc.GetDeviceCaps(LOGPIXELSY);
// almost always the same in both directions, but sometimes not!
I've never seen a case where they're different, but the fact that there are two separate calls for it strongly suggests that they might be sometimes.
Its easy for them to be different if the monitor is set up to use a screen resolution ratio that is not the same as the physical screen ratio, such as a 4:3 resolution like 1600x1200 on a 16:9 display.
Related
I'm using function CDC::Rectangle and it uses logical coordinates.
But I want to know how large is the area on which I draw, so I can for example draw rectangle 10% of area width.
How can I get dimensions of coordinate system from CDC?
Believe it or not, a Windows device context does not keep track of the boundaries of the object it's attached to. GetBoundsRect might give you something useful, or it might not, depending on the circumstances. Using the CWnd object and calling GetClientRect is the most reliable way.
Use GetClientRect to get the client size of the window (ie the drawing space for your window).
Logical coordinates are important only when your mapping mode is not MM_TEXT, in that case you would need to use CDC::LPtoDP.
You should be able to use the example in the link in your question except that
instead of rect.DeflateRect(20, 20);
use rect.right /= 10; rect.bottom /= 10;
How to detect split screen mode in windows 8. I have a wim32 desktop application(written in MFC) and i need to provide some functionality in case of split screen mode
FYI - In split screen mode both desktop and metro mode come side by side
From your comments, the reason you're getting the screen size is because that's what you're asking for. Passing SM_CXSCREEN and SM_CYSCREEN to GetSystemMetrics() will return, as the name suggests, the width and height of the primary display.
There are a number of solutions, each with their pro's and con's, the simplest of which is probably:
RECT rcDesktop;
BOOL ok = GetWindowRect(GetDesktopWindow(), &rcDesktop);
This will return the size of the desktop window of the primary monitor. If you wanted just the "useable" area (taking into account the taskbar):
RECT rc;
BOOL ok = SystemParametersInfo(SPI_GETWORKAREA, 0, &rc, 0);
In the case of having a Modern-UI app docked to the side of the screen, both of those should return what you want, depending on whether you want to cover the taskbar with your program or not.
Note that those examples will only return information for the primary monitor on multi-monitor systems. You can get information about a specific monitor, such as the monitor that your current window is located on, by doing the following:
MONITORINFO mon_info;
mon_info.cbSize = sizeof(MONITORINFO);
BOOL ok = GetMonitorInfo(MonitorFromWindow(hWnd, MONITOR_DEFAULTTONEAREST), &mon_info);
The MONITORINFO structure contains the size (and position - don't assume it's 0,0) of the requested monitor, including the work area:
Caveat: I'm not at home on my Windows8 system, so I can't check that all of these will return the correct information, but in theory checking the work area should do what you want, unless you specifically want your program to be full-screen.
I would like to get the actual screen dpi/ppi, not the dpi setting used for font in C++.
I tried with the following codes:
Version 1, reports 72 dpi, which is wrong.
SetProcessDPIAware(); //true
HDC screen = GetDC(NULL);
double hSize = GetDeviceCaps(screen, HORZSIZE);
double vSize = GetDeviceCaps(screen, VERTSIZE);
double hRes = GetDeviceCaps(screen, HORZRES);
double vRes = GetDeviceCaps(screen, VERTRES);
double hPixelsPerInch = hRes / hSize * 25.4;
double vPixelsPerInch = vRes / vSize * 25.4;
ReleaseDC(NULL, screen);
return (hPixelsPerInch + vPixelsPerInch) * 0.5;
Version 2, reports 96 dpi, which is the Windows dpi setting for font, but not the actual screen dpi.
SetProcessDPIAware(); //true
HDC screen = GetDC(NULL);
double hPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSX);
double vPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSY);
ReleaseDC(NULL, screen);
return (hPixelsPerInch + vPixelsPerInch) * 0.5;
I'm honestly confused by the answers here.
Microsoft has a GetDpiForMonitor method:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn280510(v=vs.85).aspx
And monitors DO expose their physical dimensions to tools. You can read your monitors width and height, in centimeters, using the HWiNFO64 tool. So if they're getting it (DDI?), it stands to reason that you can access that information yourself.
Even a different Stack Overflow post mentions using WmiMonitorBasicDisplayParams to get the data.
How to get monitor size
So the top post is flat-out, 100%, wrong.
What you're asking for is, unfortunately, not possible in the general case.
Windows doesn't know the physical screen size. Windows might know that your screen has 1024x768 pixels, but it doesn't know how big the screen actually is. You might pull the cable out of your old 13" screen and connect it to a 19" monitor without changing the resolution. The DPI would be different, but Windows won't notice that you changed monitors.
You can get the true physical dimensions and DPI for a printer (assuming the driver isn't lying), but not for a screen. At least not reliably.
UPDATED
As others have pointed out, there are standards for two-way communication between newer monitors and the OS (EDID), that might make this information available for some devices. But I haven't yet found a monitor that provides this information.
Even if EDID were universally available, it's still not solvable in the general case, as the display could be a video projector, where the DPI would depend on the zoom, the focus, the lens type, and the throw distance. A projector is extremely unlikely to know the throw distance, so there's no way for it to report the actual DPI.
Getting DPI information is found to produce exact value using the below method.
ID2D1Factory* m_pDirect2dFactory;
D2D1CreateFactory(D2D1_FACTORY_TYPE_SINGLE_THREADED, &m_pDirect2dFactory);
FLOAT dpiX, dpiY;
m_pDirect2dFactory->GetDesktopDpi( &dpiX, &dpiY );
I think what you're after is:
GetDeviceCaps(hdcScreen, LOGPIXELSX);
GetDeviceCaps(hdcScreen, LOGPIXELSY);
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.
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.
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
}
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.
When I print the CDC for a report control that I've created it appears tiny (less than 1 square inch on paper). How can I get the report to be printed to occupy the entire page ?
Or in other words, how can I make the entire report to appear in one printed page.
CPrintDialog printDialog(FALSE);
printDialog.DoModal();
CDC dcPrint;
if(dcPrint.Attach(printDialog.GetPrinterDC()))
{
int iHorzRes = dcPrint.GetDeviceCaps(HORZRES);
int iVertRes = dcPrint.GetDeviceCaps(VERTRES);
int iHorzResCDC = m_CDC.GetDeviceCaps(HORZRES);
int iVertResCDC = m_CDC.GetDeviceCaps(VERTRES);
dcPrint.m_bPrinting = TRUE;
dcPrint.BitBlt(0,0, iHorzRes, iVertRes, &m_CDC, iHorzResCDC, iVertResCDC, SRCCOPY);
CFont* pOldFont = dcPrint.SelectObject(&m_HeaderFont);
dcPrint.TextOut(0,0,"HelloWorld") ;
dcPrint.SelectObject(pOldFont);
CPrintInfo printInfo;
printInfo.m_rectDraw.SetRect(0,0, iHorzRes, iVertRes);
dcPrint.StartDoc("Report Print");
dcPrint.StartPage();
if(dcPrint.EndPage())
dcPrint.EndDoc();
else
dcPrint.AbortDoc();
}
dcPrint.DeleteDC();
m_CDC is the memory DC that I use to buffer and display the entire report on screen.
As others have said, this is because, in general, the display resolution of printers is a lot higher than displays. Displays are usually 96 to 120DPI: at 96DPI this means that an image of 96 pixels (dots) by 96 pixels occupies approximately 1 square inch on the display. However, if you just take that image and print it out on a 600DPI printer, the size of the image will be about 1/6" by 1/6" - much smaller. This is a bane of the publishing world - images that look fine on displays often look either tiny or terrible when printed.
You could, as has been suggested, use StretchBlt rather than BitBlt to scale up your image. Depending on the difference between your display and printer, this will either look a bit blocky, or utterly hideously blocky.
A much better option is to rewrite your code that does the drawing of the control so that you've got a method that takes a device context (and some co-ordinates) and draws into it. Your normal window painting code can pass the memory DC to this routine and then BitBlt the result to the window, and your painting code can call this method with the printer DC and some suitable co-ordinates.
When writing this routine you'll have to worry about scaling: for example, you'll need to create fonts for the given device context, and with a scaling-indepdendant size (that is, specify the font size in points, not pixels), rather than relying on a pre-created font.
I suppose that you're not scaling your report to the printer's resolution. Typical screen resolution is 72 DPI (sometimes 96 DPI). Printer resolution can be 300DPI, 600DPI or higher.
You should repaint the report to the printer DC with all coordinates and sizes scaled to the printer's resolution.
Your printer has a lot more dots per inch than your screen. You will need to scale things to fit the printed page a bit better.
Try using StretchBlt() instead of BitBlt().