Dialog has a modern look on time design , but old look on run time (using Visual C++ and resource editor)

Question

I'm creating a dialog with the resource editor of Visual C++.

When I run the test button of the editor, components of the dialog are displayed with a modern look, while when running the application that creates and shows the dialog, it's displayed with an old look...I'm just using WINAPI calls to display the dialog, not MFC.

Here are the screenshot (the upper image is an example of UI look on design time, the other one is the UI look on run time):

link text

Does anyone know what I'm doing wrong?

Strangles

Answer 1

Does your application manifest specify that you want to use comctl32.dll version 6? This is one of the requirements of using visual styles and a more modern look in windows XP.

To create a manifest and enable your application to use visual styles.

Link to ComCtl32.lib and call InitCommonControls (see the Platform SDK documentation in the MSDN Library).

Add a file called YourApp.exe.manifest to your source tree that has the following XML format:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <assemblyIdentity
  version="1.0.0.0"
  processorArchitecture="X86"
  name="CompanyName.ProductName.YourApp"
  type="win32"
 />
 <description>Your application description here.</description>
 <dependency>
  <dependentAssembly>
   <assemblyIdentity
    type="win32"
    name="Microsoft.Windows.Common-Controls"
    version="6.0.0.0"
    processorArchitecture="X86"
    publicKeyToken="6595b64144ccf1df"
    language="*"
   />
  </dependentAssembly>
 </dependency>
</assembly>

Add the manifest to your application's resource file as follows

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "YourApp.exe.manifest"

Note: When you add the previous entry to the resource you must format it on one line. Alternatively, you can place the XML manifest file in the same directory as your application's executable file. The operating system will load the manifest from the file system first, and then check the resource section of the executable. The file system version takes precedence.

Callista

Answer 2

Have you got a manifest correctly set up to use version 6 of commctl32.dll in your project? If not, you won't get the themed controls.

In later versions of Visual Studio, this is usually done with a #pragma, like so (this one is for x86, copied from a new project generated with VS2005):

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")

If you add this to one of the source files in your project and rebuild, the manifest will be generated by the linker and added to your application. For other processor architectures, you'll need to change the "processorArchitecture" value. (Why VS can't figure this out for itself is a mystery left to the reader to solve...)

(As some others have noted, you can also manually generate the manifest and add it to the .rc file. This is more long-winded, but does give you complete control of the manifest's contents.)

Enthral

Another option to set this is Project Properties Dialog. Required option in VS2010 is under Configuration Properties - Linker - Manifest File - Additional Manifest Dependencies. – Henricks

Exact value to enter when following @IvanNikitin advice: "type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'" (took me a while to figure out). source – Spondylitis

Answer 3

Some Windows Forms controls will assume their new guise as soon as the application is bound to version 6.0 of Comctl32.dll.

and how you can achieve that is described under Using Windows XP Visual Styles With Controls on Windows Forms

Zendejas

Answer 4

I have a solution for VC6, but I am not sure if it will work in VS 2008.
(also check this article for what is causing the problem)

Here is an example of a simple manifest file that I've used to solve it:

Create the below XML file,

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
                 manifestVersion="1.0">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="X86"
    name="Microsoft.Windows.YourApplication"
    type="win32"
/>
<description>YourApplication</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="X86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

First, let's add two lines to the resource.h file. Just copy and paste the following:

#define IDR_MANIFEST  1
#define RT_MANIFEST  24

Now, open the application custom resource file. Usually, it's located in the res directory; the default extention is .rc2. Manually add the following line:

// Add manually edited resources here...
IDR_MANIFEST RT_MANIFEST MOVEABLE PURE
             "res\\ApplicationManifestXMLFile"

Replace ApplicationManifestXMLFile with the actual file name (the XML you have created).

Asgard

Answer 5

The question specifies C++ and this other question shows how to do it more cleanly.

For .Net 2.0+, please see >this MSDN article< for how to do it with one line of code, to wit:

Main() 
{
    Application.EnableVisualStyles();
}

I hope this helps someone searching this topic.

Anthesis

Answer 6

Expanding on the existing answers...

MSDN: Build Requirements for Windows Vista Common Controls

Dropping the following into stdafx.h worked well for me, and helped to display at runtime the thin border styling shown in the VS dialog resource editor:

#ifdef UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_IA64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='ia64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endif

Betweenwhiles

Answer 7

If anyone finds this post for the same reason as I did, I was wondering why (in some Python app) calling PrintDlgW() resulted in a legacy print dialog instead of Win 10/11's "modern" UWP print dialog.

This was not about a missing manifest (AFAIK Python's ctypes/libffi takes care of that when loading Windows dlls like comdlg32), but it turned out that the crucial factor was field "hwndOwner" of the PRINTDLGW struct passed to PrintDlgW().

Only when you set hwndOwner to the actual window's HWND you get the modern print dialog version, if you set it to NULL (or, in Python, don't set it at all, since ctypes sets all "Structure" fields to NULL by default) you get the legacy print dialog version instead.

Profanity