Thanks for the link - Some of my projects include buth COMCTL32 and MSCOMCTL.
For toolbars and trees and listviews, in projects that that use a button menu
or require colors for LV or TV nodes (and fullrowselect), I use 6. I use 5 for the status bar and progress bar.
What are the differences between COMCTL32 (5) and COMCTL32 (6)? You have defined the issue fairly well - but are you saying there may be a method to instanciate COMCTL32 (6) by implementing a "manifest" that would allow us to designate version 6.
Have you found a way to do that with APIs - or will we have to wait for the 64bit version of VFP?:-)
>2) Windows XP uses a new feature of Windows 2000/XP to allow that DLL be installed "side-by-side" with version 5 of COMCTL32.dll. In other words, 2 DLLs with the same name/GUID to be registered on the computer at the same time and an application can use one or the other using a construct called a manifest.
>
>3) VFP8 provides inherent support for Windows themes. It contains settings for enabling themes for the application and for specific VFP controls. It also builds a manifest into executables when it compiles that tells the application which version of the common controls to use - based upon the themes settings within the application. In fact, here's the one I found embedded in my application:
>
>
><?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"
> type="win32"
> name="Microsoft.VisualFoxPro"
> processorArchitecture="x86"
>/>
><description>Visual FoxPro</description>
><dependency>
> <dependentAssembly>
> <assemblyIdentity
> type="win32"
> name="Microsoft.Windows.Common-Controls"
> version="6.0.0.0"
> language="*"
> processorArchitecture="x86"
> publicKeyToken="6595b64144ccf1df"
> />
>
>
>4) There are 3 ActiveX controls that are typically used for incorporating Windows common controls into an application:
> - COMCTL32.OCX (Version 5.x common controls)
> - MSCOMCTL.OCX (Most Version 6.x common controls)
> - MSCOMCT2.OCX (Adds Animation, UpDown, MonthView, DTPicker, and FlatScrollBar controls)
>
>5) COMCTL32.OCX calls into COMCTL32.DLL, but MSCOMCTL.OCX and MSCOMCT2.OCX do not. I'm not certain all of the libraries they DO call into, but COMCTL32.DLL is not one of them. (I found an article stating that and I verified it with a HEX editor.)
>
>-----
>Now, assuming I've got all THAT right, then I think I understand why VFP behaves as it does when rendering the common controls.
>
>- When using a Version 6 common control (from MSCOMCTL.OCX or MSCOMCT2.OCX), you don't get Windows Themes support because those libraries do not call into COMCTL32.DLL, so the manifest that VFP builds into its executables has no effect. That manifest basically tells it to use the newer COMCTL32.DLL when needed, but since those two OCX files bypass it, no themes support.
>
>- When using a Version 5 common control (from COMCTL32.OCX), you DO get Windows Themes support (if you've enabled it in your application) because the manifext that VFP8 builds into its executables tells the app to use the newer COMCTL32.DLL which knows how to render themes. However, even though that newer DLL has extended features built into it for each of its controls, COMCTL32.OCX does not know how to use it because it was originally built for version 5 common controls. Any functionality that was built into the controls at the DLL level is unavailable through that .OCX file.
>
>- The reason that Alex Grigorjev's class (Easy: Common Controls" (ID 9345)) works has nothing to do with the fact that they're not ActiveX, but that they reference COMCTL32.DLL - which VFP8's manifest is directing to the proper one.
>
>
>Does this all make sense? Have I got it right?
>
>John
Imagination is more important than knowledge
