Why does an attempt to create a SysLink control in my plug-in sometimes fail?


A customer had written a plug-in for some application, and they found that their plug-in was unable to create a SysLink control via the Create­Window­ExW function. The same code in a standalone application works fine, but when the code is placed in their plug-in, the code fails.

Debugging showed that the call to Init­Common­Controls­Ex succeeded, but the Create­Window­ExW call failed with "Cannot find window class."

The customer is another victim of not keeping their eye on the activation context.

They attached a manifest to their DLL so that the call to Init­Common­Controls­Ex maps to the version of the common controls library that supports the SysLink control. But they did nothing to ensure that that context was active at the time they called Create­Window­ExW.

The customer's plug-in clearly falls into the case Adding Visual Style Support to an Extension, Plug-in, MMC Snap-in or a DLL That Is Brought into a Process. but they failed to follow the instructions provided therein (which boil down to "use isolation awareness").

From the symptoms, it appears that the host application for their plug-in does not activate a version-6 common controls manifest at the time it calls into the plug-in, which means that your attempt to create version-6 common controls will fail.

On the other hand, the standalone application probably uses the technique given in Using ComCtl32.dll Version 6 in an Application That Uses Only Standard Extensions, which activates the version-6 common controls when the process starts and leaves it active for the duration of the process.

Comments (1)
  1. Ian Boyd says:

    The way it works is interesting, and should actually be mentioned somewhere.

    When you add the define `ISOLATION_AWARE_ENABLED`, then all the important functions in the Windows header header files are replaced with "Isolation Aware" versions.

    E.g. `CreateWindowExW` is replaced with `IsolationAwareCreateWindowExW`.

    What the IsolationAwareXxxx versions of every function is to basically:

       ActivateActCtx(ref cookie);

          CreateWindowExW(…);

       DeactivateActCtx(cookie);

    And then this `IsolationAwareCreateWindowExW` function is defined to replace the real `CreateWindowExW` function. So that means any call to any function that depends on activation context automatically call ActivateActCtx/DeactivateActCtx for you.

    For those of us developing native Windows application not using C/C++ or the Windows header files, this is a useful piece of information.

Comments are closed.

Skip to main content