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.
Related
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.
I am posting here on the off-chance that someone knows why my screen size is reported as 611 instead of 600?
GetSystemMetrics(SM_CYFULLSCREEN)
returns 611. My netbook is 1024x600, so I expected 600, not 611.
Googling for 1024x611 turns up a surprising number of results, also.
from other forum threads, it seems that GetSystemMetrics(SM_CYFULLSCREEN) does not always return the exptected result. it seems to be adjusted, and may not be the value you want.
try using GetSystemMetrics(SM_CYSCREEN), which will return the size of your primary monitor.
(also, note that some people use multiple monitors: take care of not constraining your application to a single monitor)
SM_CXFULLSCREEN and SM_CYFULLSCREEN returns the size of a full screen window, so would usually be less than your screen size due to the taskbar:
The width of the client area for a full-screen window on the primary
display monitor, in pixels. To get the coordinates of the portion of
the screen that is not obscured by the system taskbar or by
application desktop toolbars, call the SystemParametersInfo function
with the SPI_GETWORKAREA value.
Compare it to what SPI_GETWORKAREA in SystemParametersInfo returns for your display? Or what is your display set to in the control panel??
A 1024x640 screen would be a true 16:10 ratio and would amount to ~ 611 y available desktop size.
I want to adjust a Static control's size to its content size, so I need to calculate the size of its text content first. I found a way to use GetTextExtentPoint32 to calculate the size, but I need to set the DC's font to the same as the control's font first. Is there a better way to do this? I've set the Static control's font once, I think maybe I don't need to set the DC's font the second time.
What is the best way to calculate the size of a Static control's text content? And is there a better way to autosize the Static control?
It sounds to me like you've already figured out the correct way to do it. Call GetTextExtentPoint32 to figure out the ideal size of the control given the text that it contains, and then resizing the control to the calculated size.
It's a lot of work, but that's what happens when you're working with the raw Win32 API. You don't have a handy wrapper library that abstracts all this for you in a Control.AutoSize() function. You could easily write your own function and re-use it, but the Win32 standard controls do not expose an "auto-size" API.
As far as the font, you will definitely need to make sure that the device context is using the same font as the control, otherwise you'll calculate the wrong size. But you don't have to create a new device context, request a handle the static control's font, and select that into your new DC. Instead, you can just use the static control's DC using the GetDC function and passing in the handle to your static control window. Make sure that if you call GetDC, you always follow up with a call to ReleaseDC when you're finished!
However, do note some caveats of the GetTextExtentPoint32 function that may interfere with the accuracy of the size you calculate:
It ignores clipping.
It does not take into account new lines (\n) or carriage returns (\r\n) when computing the height.
It does not take into account prefix characters (those preceded in the string with ampersand) and used to denote keyboard mnemonics if your static control does not have the SS_NOPREFIX style.
It may not return an accurate result in light of the kerning that may be implemented automatically by some devices.
(This is all mentioned in the linked documentation, but does anyone actually read that?)
Perhaps an easier alternative is to draw the text the same way that the static control is already doing. Unless you have the SS_SIMPLE style set (which uses TextOut or ExtTextOut to draw text as an optimization), static controls draw their text by calling the DrawText function with the appropriate parameters, given the other control styles that are set (reference).
You can do exactly the same thing, and add the DT_CALCRECT flag in your call to the DrawText function, which causes it to determine the width and height of the rectangle required to draw the specified text without actually drawing the text.
Most windows using static text controls are dialogs, where the static control's size is expressed in dialog units (DLU), which account roughly for the size of the font. In this way, dialog controls tend to have sensible sizes.
If you are not using dialogs, you can attempt to fake dialog behavior using MapDialogRect.
Otherwise yes you must use GetTextExtentPoint32.
There is no autosize for static control as far as I know. You are doing it correct.
Use GetWinDowText to get the text of static window
Use GetDC to get the dc for the window
Use WM_GETFONT to get the font for the window and select the font into the dc
Use one of the text size calculation function to calculate the text size
Restore the the original dc font
Release dc
You will always have to select the proper font into the dc to get accurate result. Also I personally prefer DrawText with DT_CALCRECT to calculate the size of a text. Refer http://msdn.microsoft.com/en-us/library/windows/desktop/dd162498%28v=vs.85%29.aspx
With DrawText, you dont have to supply the character count if the text is NULL terminated. Plus you can combine various formatting option to adjust the calculation. For example, an Ampersand(&) character in a static control text underlines the next character. With Drawtext you will be able to calculate the size properly but in GetTextExtentPoint32 there is no provision to specify this.
I have a cursor what the size size 128x128, but when i used LoadCursor to load and show it, it only has 32x32. Which API can make it correctly? It seems MS resize it. Thanks.
Windows XP does not include any system cursors that are larger than 32x32. (If larger cursors were included, they would be stretched down to 32x32 when the standard APIs load the cursors.)
For high-DPI systems, Windows XP has adjusted the SM_CXCURSOR and SM_CYCURSOR values to be 64x64 pixels. This size adjustment is to prevent the mouse pointer from virtually disappearing because it is too small to be effectively used. Although the other aspects of the system scale with DPI, the mouse pointer does not scale. Microsoft does not try to enforce a DPI-independent size for the mouse pointer.
The system also provides the SetSystemCursor API function that you can use to change the system cursor for specific categories. You can use this function to set a cursor of any size. However, you must call the function programmatically, and you can only use it to set a cursor for a specific category. You cannot use it to make all cursors on the system the same size.
http://support.microsoft.com/kb/307213
Don't use LoadCursor, use LoadImage() instead.
SM_CXCURSOR by SM_CYCURSOR is the only cursor size the system can currently use.
Use GetSystemMetrics to find out those values.
I was trying some code to capture part of the screen using getPixel on Windows, with the device context being null (to capture screen instead of window), but it was really slow. It seems that GetDIBits() can be fast, but it seems a bit complcated... I wonder if there is a library that can put the whole region into an array, and pixel[x][y] will return the 24 bit color code of the pixel?
Or does such library exist on the Mac? Or if Ruby or Python already has such a library that can do that?
I've never done this but I'd try to:
Create a memory Device Context (DC)
using CreateCompatibleDC passing it
the Device Context of the desktop
(GetDC(NULL)).
Create a Bitmap (using
CreateCompatibleBitmap) the same
size as the region your capturing.
Select the bitmap into the DC you
created (using SelectObject).
Do a BitBlt from the
desktop DC to the DC you created (using SRCCOPY flag).
Working with Device Contexts can cause GDI leaks if you do things in the wrong order so make sure that you read the documentation on all the GDI functions you use (e.g. SelectObject, GetDC, etc.).