Runtime activation of Common Controls v6 (Manifest-free alternative)

[Patrice Terrier]

Runtime activation of Common Controls v6 (Manifest-free alternative)

For years, the standard way to enable modern Windows visual styles (ComCtl32 v6) has been through a manifest, either embedded or via:

Code: [Select]

// Include the v6 common controls in the manifest
#pragma comment(linker,""/manifestdependency:type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"")

While this works, it introduces a dependency on the linker and can sometimes lead to inconsistent behavior depending on build settings, resources, or memory conditions.


Alternative: Runtime activation (no manifest required)

It is possible to activate visual styles dynamically at runtime using an activation context (ACTCTX).
This method loads the ComCtl32 v6 resources directly from shell32.dll.

Code: [Select]

static BOOL EnableVisualStylesRuntime(VOID) {
    BOOL bRet = FALSE;
    WCHAR dir[MAX_PATH];
    DWORD cch = GetSystemDirectory(dir, MAX_PATH);
    if (!cch || cch >= MAX_PATH) return bRet;

    ACTCTX actCtx; ClearMemory(&actCtx, sizeof(actCtx));
    actCtx.cbSize = sizeof(actCtx);
    actCtx.dwFlags = ACTCTX_FLAG_RESOURCE_NAME_VALID | ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID;
    actCtx.lpSource = TEXT("shell32.dll");
    actCtx.lpAssemblyDirectory = dir;
    actCtx.lpResourceName = MAKEINTRESOURCE(124);

    HANDLE hActCtx = CreateActCtx(&actCtx);
    if (hActCtx != INVALID_HANDLE_VALUE) {
        ULONG_PTR ulActCookie = 0;
        if (ActivateActCtx(hActCtx, &ulActCookie)) {
            bRet = TRUE;
        } else {
            ReleaseActCtx(hActCtx);
        }
    }
    return bRet;
}

Important notes

* Must be called very early (ideally at the start of wWinMain or inside your core init like skInitEngine).
* Affects all subsequently created controls (ComboBox, ListView, TreeView, etc.).
* Ensures consistent theming without relying on external manifests.
* Particularly useful in:
   - CRT-free builds
   - DLL-based UI engines (e.g. WinLIFT)
   - Custom control frameworks
* Avoid calling it after controls are already created.


Why this matters

In practice, inconsistent behavior of controls (especially owner-drawn or themed ones) often comes from:

* Missing or partial v6 activation
* Timing issues (controls created before activation)
* Resource/memory edge cases

By forcing activation at runtime, behavior becomes deterministic and uniform.


Conclusion

This approach is a reliable replacement for manifest-based activation and gives full control over when and how visual styles are enabled.

In my case, integrating this directly into the initialization phase removed all inconsistencies without requiring any manifest handling.


Tip

If you already use a framework like WinLIFT, placing this call inside the engine initialization guarantees that all controls benefit from v6 styling automatically.