SftTabs/DLL 7.0 Documentation

Per-Monitor DPI and Scaling

SftTabs/DLL 7.0 is fully Per-Monitor v2 DPI-aware. A tab control hosted on a Per-Monitor v2 aware top-level window will re-render automatically when its window moves to a monitor of a different DPI or when the system DPI changes. The control owns the metrics it controls; the caller owns the images and fonts it provides. Two opt-in flags let the caller hand those over to the control as well.

Host setup

The host application must declare Per-Monitor v2 DPI awareness. This is the single most common reason SftTabs/DLL 7.0 applications do not re-render correctly when moved between monitors of different DPI. Without a PMv2 declaration, Windows silently keeps the process in System-aware mode: the DPI is fixed for the process lifetime, SftTabs does not observe DPI changes, SFTTABSN_DPI_CHANGED is never raised, and high-DPI monitors render at System-DPI sizes stretched by Windows. Visual Studio's default app.manifest does not declare PMv2 awareness - the developer must opt in explicitly.

Two approaches - pick one:

Application manifest (recommended)

Add a <dpiAwareness> / <dpiAware> element to the application manifest. Both elements are usually included for back-compatibility with older Windows 10 builds:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <asmv3:windowsSettings>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

In a Visual Studio C++ project, set Project Properties -> Manifest Tool -> Input and Output -> Additional Manifest Files to the .manifest file above, or edit the auto-generated manifest directly. In a C# / .NET project, check Application -> DPI awareness and select Per Monitor V2.

Runtime API

Alternatively, call SetProcessDpiAwarenessContext at process startup, before any window is created:

SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);

Caveat: This call must run before the first window (including hidden startup dialogs or splash screens) is created. If a window has already been created, Windows rejects the call and the process remains in whichever mode the manifest specified - which, with the Visual Studio default, is System-aware.

Verifying the declaration worked

Quick check at runtime: GetDpiForWindow on the tab control returns the current monitor's DPI - 96 at 100%, 120 at 125%, 144 at 150%, 192 at 200%. If the returned value never changes as you drag the window between monitors with different scale factors, the host is not in PMv2 mode.

What scales automatically

When the host is Per-Monitor v2 aware, the tab control scales these metrics itself on every DPI change without any caller involvement:

• tab heights and row heights,
• scroll button sizes,
• focus rectangle thickness,
• close / minimize / restore button sizes,
• 3D frame widths.

What the caller controls

Two independent opt-in flags let the caller choose whether caller-supplied pixel metrics and caller-supplied images also scale with DPI. Both default to back-compatible behavior (no automatic scaling) so existing applications keep working unchanged.

Decision guide

Caller responsibilities on DPI change

When the control's monitor DPI changes, SftTabs raises SFTTABSN_DPI_CHANGED to the parent window. The application should:

• re-send WM_SETFONT with a font sized for the new DPI (SftTabs does not own the application's font),
• if SetImageScaling is ASIS and the caller wants crisp images, re-register tab pictures (SFTTABS_TAB, TabPicture / TabPicture2) at the new physical size,
• if SetImageScaling is STRETCH, no action needed - the control scales existing images automatically,
• if SetPixelScaling is ASIS, re-apply margins / indent / forced size scaled for the new DPI,
• if SetPixelScaling is STRETCH, no action needed - the control scales stored values automatically.

Owner-draw

The SFTTABS_DRAWINFO structure carries the control's current effective DPI in its dpi field. Owner-draw code should read this value on every paint and must not cache pixel metrics across callbacks. GetDPI returns the same value outside a paint callback.

Platform note: Per-Monitor v2 DPI awareness requires Windows 10 version 1703 or later. On older platforms the host process runs in System-aware or Unaware mode and DPI is effectively fixed for the process lifetime - SftTabs still renders correctly but does not fire SFTTABSN_DPI_CHANGED.