See Also
 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
UI elements whose positions and sizes are specified in pixel coordinates that assume 96-DPI will be incorrect in high DPI. In general, all UI elements should be laid out using scaled positions and sizes, or relative to controls, fonts, or system metrics.
The GetDeviceCapsWindows Embedded CE-based function can be used to obtain a display's DPI by passing in either LOGPIXELSX or LOGPIXELSY as the second parameter. The CrosswordSample demonstrates how you can define SCALEX and SCALEY macros to apply a scaling factor based on information from GetDeviceCaps.
You can continue to work in pixels but remove assumptions about the DPI by:
- Using the SCALEX and SCALEY macros to scale 96-DPI pixel
coordinates, or using the metrics returned by GetSystemMetrics.
- Expressing sizes or positions relative to other controls.
- Expressing sizes or positions relative to a font.
Dialog boxes already use font sizes to determine their layout, so typically they need no special modification to work on high-DPI devices.
Here is an example of positioning a window with DPI awareness, where x, y, dx, and dy are pixel coordinates in 96-DPI:
 Copy Code
|
|
|---|---|
SetWindowPos(hwnd, NULL, SCALEX(x), SCALEY(y), SCALEX(dx), SCALEY(dy), SWP_NOZORDER); |
|
If you choose to scale 96-DPI pixel metrics, be aware of rounding problems when using integers. For example, SCALEX(a + b) may not equal (SCALEX(a) + SCALEX(b)) because of rounding issues.