The problem is, the program is always exiting code 1, meaning that InitCommonControlsEx() failed.
I REALLY don't know why this is happening, as I #included <commctrl.h>, linked with ComCtl32.lib, and the "Modules" tab says that the linker had loaded the symbols.
Funny thing, is that in the list of .dll files that are loaded in the Modules tab, comctl32.dll is listed twice - and if i don't add the .lib in the linker, I get unresolved external symbols.
So, if anybody knows what i'm doing wrong, any help would be appreciated.
Sounds like your code is linked to the 'classic' v5 version of comctl32.dll. That version doesn't handle ICC_STANDARD_CLASSES since in classic style apps those components are handled by user32.dll (they're the ones that look like they're from Win95). The updated or XP style controls are handled by comctl32 but a manifest is required to pull in the proper dll version. There's an example of a v6 manifest here if you Page Down twice, along with more than anybody needs to know about the process.
And then, there's multiple .dll files with the same name - one in the System32 folder, the others one are in x86_microsoft-windows-shell-comctrl32-v5.... and some are in x86_microsoft.windows.common-controls....
And how do I get the manifest file? Do all versions of Windows come with the comctl32.dll that I need?
Since around XP, Windows has been keeping (several copies of) both v5 and v6 around. V5 is for old programs written for 2000, 98, etc. and v6 is for XP+. Without a manifest in your program, Windows has no way of knowing which version you want. Since it was XP that introduced manifests, if your program doesn't include one specifically asking for v6 Windows assumes your program was written for < XP and loads v5.
If you're using VS2008 or 2010 you can usually just add a PROGNAME.exe.manifest and VS will automatically find it and link it in. Just copy/paste and customize one from teh interwebs and usually it'll work fine. Just be sure it's actually right, I've been bitten by that before.
When I compiled the program, Visual C++ actually deleted my manifest file... Not sure why, though.
It still didn't work. Was it supposed to go into the Debug folder, or with the source code?
Also, I was looking through the automatically generated .manifest files, and one of the manifests (PROGRAMNAME.exe.embed.manifest) already has the same info as MSDN's example (with version 6.0.0.0) for common controls. I don't know what I did to get it actually working, but then it stopped working, then I rebuilt the program and the automatically generated manifest didn't contain the common controls section anymore...
Was it supposed to go into the Debug folder, or with the source code?
I put the manifest with the source code for VS to embed it into the .exe. In theory you should also be able to put it into the Debug/Release folder and the OS should find it, but that's one more file to distribute.
VS merges the various .manifest files before embedding them, so that might have something to do with it.
[quote name='adam4813']
In Visual Studio (may work with others) you can explicitly tell the manifest tool to add the common-controls v 6.0.0.0 line using;
You could, but I personally prefer to have the manifest as its own separate file. For one, you don't have to recompile anything if you change something. Plus once you start getting more dependencies and other manifest attributes (like description and version and OS compatibility) you might as well use the manifest file.
Hmm. I've been wondering for some time why ComboBox_SetCueBannerText doesn't actually do anything when I try to use it. Perhaps this is the answer. Thanks for the tip.
