asked on

XP look disappears with MFC9

I have an MFC application that has used XP look for many years (previously built with VS23003 and MFC7). When rebuilt with MFC9 (and MFC10) it reverts to old (W2K) look. Ie, the buttons are an ugly grey with square corners, and there is no mouse over highlighting of buttons, tabs etc.

I have spent a huge amount of time researching this to no avail. And yes, I have included the manifest (tried both as resource and separate .exe.manifest file). I have also tried many other things to numerous to list.

Its obvious it can work as the samples show the correct look. However, I have tried many approaches but it is very difficult to isolate what is causing the problem. I have tried selectively removing parts of the program but the problem still happens (until I remove so much that it is impossible to get it to compile and run).

There must be a way to find out why the "XP look" is not being applied but I have yet to find any information from MS or elsewhere that documents what is happening behind the scenes.

ASKER CERTIFIED SOLUTION

JimBeveridge

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Pramod Bugudai

Hi. In the desktop Right Click your mouse. In the context menu go to Properties. In the Properties dialog select appearance tab. Select "Windows XP style from the drop down list of "Windows and buttons". Click apply. Now run your application. Hope this solves your problem.

aphillips

ASKER

Thanks for the replies.

JimBeveridge said:
> You didn't say exactly what was in your manifest ...

I am not sure where I got the manifest, but it worked fine in previous versions of MFC. I will compare it with the ones that work but FYI here it is in full:

<?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="ECSoftware.HexEdit.HexEdit"
type="win32"
/>

<description>Windows hex editor.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

JimBeveridge said:
> make sure your InitInstance() function has a call to EnableCommonControls

Do you mean InitCommonControls? It is there.

pramodbugudai said:
> Select "Windows XP style ...

This is already selected. I should have mentioned that this only happens with this program and on several XP, Vista and W7 systems. Also other programs (including earlier versions of this one) have the XP look on my system.

aphillips

ASKER

I tried many variations on my manifest all to no avail.

What I was hoping for is some sort of way to detect if the option is on. The I can track down the problem code that is disabling it. It is pretty clear that it is a chnage I had to make when converting my BCG code to MFC9, but there were a large number of changes and it is difficult to test each of them in isolation.

Unlike most aspects of Windows programming this is very difficult to diagnose as there is no suppoprt from the OS, AFAIK.

HawyLem

Have you tried these steps?

http://www.codeguru.com/cpp/controls/controls/article.php/c5227

The old way to have xp-style

aphillips

ASKER

I finally worked it out. It had nothing to do with any of the new MFC9 code or my initialization code, as I suspected.

Basically I was modifying a manifest file (manifest.xml in my project), but this was not the one being added to the RT_MANIFEST resource in the .EXE. I did open the .EXE in the resource editor and it seemed that the manifest was being added but this was a different manifest than mine and didn't have the <dependentAssembly> for the common controls.

Apparently when I converted my VS2003 to VS2008 the conversion process created a new manifest and simply ignored mine. (There was probably a warning about this in the conversion log but I missed it amongst the hundreds of other warnings.)

The solution was to add my manifest to one of the project properties fields. When I added it in the "Additional Manifest File" field it was merged into the manifest in the .EXE. The RT_MANIFEST resource then had the common controls stuff and it all worked. Simple, once you know what is wrong!

If I had followed Jim's advice exactly I would have spotted the problem, so I award him the points.

JimBeveridge

Great work. I have been down this path before :-)

The standard configuration is as follows:
- Set the UAC information in Property Pages/Linker/Manifest File
- Set the Common Controls manifest with a pragma in your code. (see below)
- Put custom manifest information in your external manifest file.

#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