Differences between GetDC() and BeginPaint()? - winapi

I am having trouble with some of my owner drawn listboxes on High DPI monitors on Windows 10 in a dialog box. The text is chopped off at the bottom. We saw the problem on Windows 7 and were able to fix it. It is not necessarily High DPI, but when the user sets a different text scaling. I solved the problem, so I thought (!), by using a CClientDC (wrapper around GetDC()) and calling GetTextMetrics() to determine the text height. Previously, our icons had always been taller than our text so it was not a problem. With larger DPI monitors we saw some customers reporting problems when they scaled the text.
Now we are getting new reports under Windows 10. The former problem is fine under Windows 7--but Windows 7 only scales to 100, 125, and 150 percent. Windows 10 (and maybe 8? -- but no customer reports) allows user defined scaling.
So, I tracked down the problem somewhat... I knew what the font height was when I called GetTextMetrics() during WM_MEASUREITEM. I went and put some code in to debug what GetTextMetrics() was during my WM_DRAWITEM. Well, they were different--20 pixels high during WM_MEASUREITEM, and 25 pixels high during WM_DRAWITEM. Obviously, that is a problem. I want the GetTextMetrics() to have the same results in both places.
My thought was that the only real difference I could think of was that during WM_MEASUREITEM I am calling GetDC() via CClientDC constructor, and that during WM_DRAWITEM I am using an already constructed HDC (which probably was from a return of GetPaint() inside GDI32.dll or another system DLL).
I thought maybe the BeginPaint() does something like select the windows HFONT into the HDC...
So, inside my WM_MEASUREITEM after getting the DC, I select the font of the listbox into the HDC, and then I call GetTextMetrics(). Lo and behold, the numbers match now in WM_MEASUREITEM and WM_DRAWITEM.
However, I don't know if I just got lucky. It's all just guesswork at this point.
Does BeginPaint() select the window font into the DC whereas GetDC() does not? Does the default handler of WM_PAINT for an owner drawn LISTBOX or COMBOBOX do something like select the window font into the paint DC?
BOOL DpiAwareMeasureGraphItem(LPMEASUREITEMSTRUCT lpM, CWnd* pWnd)
{
int iItemHeight = INTERG_BITMAP_HEIGHT + 4;
if (pWnd)
{
CClientDC dc(pWnd);
if (dc.GetSafeHdc())
{
CFont* pOldFont = dc.SelectObject(pWnd->GetFont()); // seems to fix it on Windows 10, but is it luck?
TEXTMETRIC tm;
memset(&tm, 0, sizeof(tm));
dc.GetTextMetrics(&tm);
LONG tmHeight = tm.tmHeight + 4; //pad
iItemHeight = max(iItemHeight, tmHeight);
dc.SelectObject(pOldFont);
}
}
lpM->itemHeight = iItemHeight;
return (TRUE);
}

Neither GetDC() or BeginPaint() initialise the DC they return with anything other than the default system font. But WM_DRAWITEM is different - it gives you an already-initialised DC to draw into.
The method you stumbled across is the right one. WM_MEASUREITEM doesn't supply a DC at all, so if you need one for size calculations you're responsible for obtaining it and setting it up with the appropriate font.

Related

Twips, please give information how to handle this [duplicate]

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);

how to find the width of fixed pitch font [duplicate]

I'm maintaining an application using Borland C++ Builder 6 running on Windows 7.
The application is incorrectly drawing text using font Courier New because each letter is being slighty cut off. The issue is when calling the method GetTextMetrics because it is filling the TEXTMETICS struct with differing tmAveCharWidth and tmMaxCharWidth values. The application then uses tmAveCharWidth to calculate character width with is wrong because that value it can be less than tmMaxCharWidth. That issue I will be fixing.
I courious why GetTextMetrics is returning differing tmAveCharWidth and tmMaxCharWidth values for Courier New? My understanding was that Courier New is a monospaced font and that tmAveCharWidth and tmMaxCharWidth should be the same. I tested with other monospaced fonts that that assumption is correct.
This is the section of code with the issue:
hFont = CreateFontIndirect(&lpInstData->lf);
hDC = GetDC(hWnd);
hFontOld = SelectObject(hDC, hFont);
GetTextMetrics(hDC, &tm);
lpInstData->nCharHeight = tm.tmHeight;
lpInstData->nCharWidth = tm.tmAveCharWidth; <--- Should be using tmMaxCharWidth
Here is the code running when I selected size 12 Courier New.
Parameter passed to CreateFontIndirect
TEXTMETRICS structure returned from GetTextMetrics
I found this was indeed ClearType at work (thanks Deanna). Turning off ClearType corrects the display issue without changing any code, although I still need to correct how the application works with ClearType.
I also found the issue was not present on Windows XP because ClearType is turned off by default, whereas in Windows 7 (and Vista) it is turned on by default.

DPI awareness: could I be told when I need to recalculate my text height so I don't have to do it all the time? And SM_CYSMICON/checkbox heights too?

A frequent operation in my Windows Table control, which I am reworking and moving into a DLL, is to get the height of a row. This is the maximum of
the height of text in the current font, in pixels
the current small icon height, in pixels (GetSystemMetrics(SM_CYSMICON))
the height of checkboxes, in pixels (determined on a WM_THEMECHANGED, when checkbox information is recalculated)
Calculating the text height, as far as I know, requires getting a DC, selecting the font in (and getting the SYSTEM_FONT if that's NULL), getting the text metrics, selecting the font out, and releasing the DC, all of which can error out/fail/etc. This means that virtually every function in my control can fail.
I can avoid this by storing the text height somewhere else, only calculating it when it changes. I know that text height is a property related to the DPI of the DC that GetDC(hwnd) returns. I would like my control to be DPI-agnostic because DPI awareness is per-process, not per-DLL/per-window.
At the same time, knowing when GetSystemMetrics(SM_CYSMICON) changes would also be useful.
So my questions are simple:
Is there a message that I can look for that will tell me that my DPI has changed and that I need to recalculate my text height?
Is there a message that will tell me that SM_CYSMICON has changed and that I need to recalculate everything? Is it the same one? (I know there is no reliable way to detect a GetSystemMetrics() failure (since 0 is a valid return and it does not set the last error code), so I am assuming it cannot fail with a valid parameter and am simply calling it each time I need to calculate the row height; this is just so I can queue a redraw when the value does change.) Would it also work for SM_CXSMICON?
In addition, looking back at my code, GetThemePartSize() takes a DC as well; do theme items like checkbox images scale with DPI? And if so, what messages do I look for in that case? The same one?
Alternative: is there a non-failing way to get the text height that I don't know about, given only a HWND and HFONT?
I will be happy to take a solution that was introduced in either Windows XP or Windows Vista; if there's a solution that was introduced in a newer version of Windows, then knowing about it could also be beneficial.
Thanks.

Can I select a font into a DC from GetDC(NULL)?

What is the difference between GetDC(hwnd) and GetDC(NULL)? I understand that the latter gets a DC for the entire (virtual) screen, but I'm not sure what that means practically.
I want to set the size of an initial window based on the font in use. I use CreateFontIndirect to create the font handle but, in my opinion, only when you SelectObject that font into a DC can you use GetTextMetrics to figure out the actual height used rather than one specified. I'm going on the assumption that they may not be the same.
I would normally use GetDC(hwnd) to get a DC and select the font into it. But, given I don't have a hwnd yet, can I select a font into a DC returned from GetDC(NULL)?
Edit: Related. I guess it may make no difference! GetDC(NULL) gets primary monitor or virtual screen?
You don't own the screen DC and should not select objects into it. What you can do is use CreateCompatibleDC, passing the screen DC, to get a DC into which you can perform text metrics calculations.

Win32 Toolbar Custom and Default icons on same bar

I realize win32 toolbar icon questions are common here, but none are relevant to my particular problem (most concern image lists, or associating with a bitmap handle).
I am trying to associate a toolbar button with an icon resource within my application. Since I am adding it to a toolbar that already has default images using TB_ADDBITMAP (new, open, save, etc), I cannot use an image list, as the article on MSDN says here:
The TB_SETIMAGELIST message cannot be combined with TB_ADDBITMAP. It also cannot be used with toolbars created with CreateToolbarEx, which calls TB_ADDBITMAP internally. When you create a toolbar with CreateToolbarEx or use TB_ADDBITMAP to add images, the toolbar manages the image list internally. Attempting to modify it with TB_SETIMAGELIST has unpredictable consequences.
MSDN says I should be able to use a resource directly with TB_ADDBITMAP, under the TBADDBITMAP::nID field:
If hInst is NULL, set this member to the bitmap handle of the bitmap with the button images. Otherwise, set it to the resource identifier of the bitmap with the button images.
The VS2008 resource editor shows a single 16x16 icon resource with the id IDI_ARROWLEFT. (I had a screenshot, but since I do not have enough "reputation" to post images you'll have to take my word for it)
This is clearly a valid icon as the following code makes the icon appear on the titlebar of the main window:
wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_ARROWLEFT));
The problem is the resource icon is not appearing on the toolbar button within the window. Below is the sample code that is loading the resource and applying it to the toolbar button:
void populateToolbarTest()
{
int index = -1;
TBADDBITMAP tbab;
TBBUTTON tbb;
ZeroMemory(&tbab, sizeof(TBADDBITMAP));
ZeroMemory(&tbb, sizeof(TBBUTTON));
SendMessage(hWndToolbar, TB_BUTTONSTRUCTSIZE, (WPARAM) sizeof(TBBUTTON), 0);
tbab.hInst = hInst;
tbab.nID = IDI_ARROWLEFT;
// SendMessage returns 0 when testing
index = SendMessage(hWndToolbar, TB_ADDBITMAP, 1, (LPARAM)&tbab);
if (index == -1) return;
tbb.iBitmap = index;
tbb.fsState = TBSTATE_ENABLED;
tbb.fsStyle = TBSTYLE_BUTTON;
// result is set to 1 when testing
LRESULT result = SendMessage(hWndToolbar, TB_ADDBUTTONS, 1, (LPARAM)&tbb);
}
This code successfully produces a button. However, there is no icon displayed, unlike with the defaults that I used in IDB_STD_SMALL_COLOR
I finally got it working. Turns out, it had nothing to do with the code.
Microsoft is EXTREMELY picky about the EXACT format of the image being referenced. It you use TB_ADDBITMAP with a custom image, it MUST be 256 colors, it MUST have the MS-Specific index format, and the only color I've gotten to register as transparent is black. I spent an hour in Photoshop messing with different formats and colors before figuring this out.
The clue was the CreateMappedBitmap function in the example on MSDN. The page on CreateMappedBitmap had this statement:
This function is fully supported only for images with color maps; that is, images with 256 or fewer colors.
What it doesn't mention is that this is true regardless of whether you use this function or not. I have tried each scenario with and without this helper function, as well as tried every other 256-color BMP index format. Some other formats managed to show up, but they were mangled.
Theoretically, you can use the CreateMappedBitmap COLORMAP to specify a transparency color other than black, but I'm not familiar enough with the "6 level RGB" format to know how to specify an exact color.
(ref: http://en.wikipedia.org/wiki/List_of_software_palettes#6_level_RGB)
Unless you're mixing custom icons with default ones, I would recommend sticking with TB_SETIMAGELIST. From what I've read, it's much more flexible (for example, it accepts more than 256 colors.)
(ref: Win32 Toolbars and 24bit Images)

Resources