Recent Posts1
64-bit SDK programming / Runtime activation of Common Controls v6 (Manifest-free alternative)
« Last post by Patrice Terrier on April 02, 2026, 10:13:13 am »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:
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.
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.
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 HANDLE g_hActCtx = INVALID_HANDLE_VALUE;
static ULONG_PTR g_ulActCookie = 0;
static BOOL g_bActCtxActive = FALSE;
static BOOL EnableVisualStylesRuntime(VOID) {
WCHAR dir[MAX_PATH];
DWORD cch = GetSystemDirectory(dir, MAX_PATH);
if (!cch || cch >= MAX_PATH) return FALSE;
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);
g_hActCtx = CreateActCtx(&actCtx);
if (g_hActCtx == INVALID_HANDLE_VALUE) return FALSE;
if (!ActivateActCtx(g_hActCtx, &g_ulActCookie)) {
ReleaseActCtx(g_hActCtx);
g_hActCtx = INVALID_HANDLE_VALUE;
return FALSE;
}
g_bActCtxActive = TRUE;
return TRUE;
}
static VOID DisableVisualStylesRuntime(VOID) {
if (g_bActCtxActive) {
DeactivateActCtx(0, g_ulActCookie);
g_bActCtxActive = FALSE;
g_ulActCookie = 0;
}
if (g_hActCtx != INVALID_HANDLE_VALUE) {
ReleaseActCtx(g_hActCtx);
g_hActCtx = INVALID_HANDLE_VALUE;
}
}
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.
