Mike Williams
10/27/2011 5:48:00 PM
"MM" <kylix_is@yahoo.co.uk> wrote in message
news:ehkia71cuf583dgtgg9o8pss2ob9ga4o9e@4ax.com...
> The latest problem I have with MMM is that it generates
> TWO comClass entries for every control, e.g.
> <comClass clsid="{1EFB6596-857C-11D1-B16A-00C0F0283628}"
> tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}"
> threadingModel="Apartment" progid="MSComctlLib.TabStrip.2"
> description="Microsoft TabStrip Control" />
> <comClass clsid="{24B224E0-9545-4A2F-ABD5-86AA8A849385}"
> tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}"
> threadingModel="Apartment" progid="MSComctlLib.TabStrip.2"
> description="Microsoft TabStrip Control" />
> The above duplication (with different clsid but same tlbid) is
> repeated for every control in the manifest, e.g. Microsoft Toolbar
> Control, Microsoft StatusBar Control, Microsoft ProgressBar Control,
> TreeCtrl.2 (i.e. TreeView), ListViewCtrl.2, ImageListCtrl.2, Slider.2,
> ImageComboCtl.2, and TabDlg.SSTab.1.
> I then have to remove the second entry in each case, and then the
> application loads okay. One day I'll get around to looking at the MMM
> source code and seeing how it works.
I don't know which version of MMM you are using but I've just tried a number
of different versions of MMM on my own machine, including the latest version
9, and I cannot reproduce your problem, regardless of how many of the
various Windows Common Controls ocx files I select in Project / Components.
No matter what I try I always get a MMM manifest which shows only the one
correct reference to the various controls. For example, in the specific case
of the TabStrip control in Microsoft Windows Common Controls 6.0 (SP4) I get
one entry in the MMM manifest, as follows:
<comClass clsid="{1EFB6596-857C-11D1-B16A-00C0F0283628}"
tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}"
threadingModel="Apartment" progid="MSComctlLib.TabStrip.2"
description="Microsoft TabStrip Control" />
As you can see, the clsid and the tlbid are both exactly the same as the
clsid and the tlbid in the first of the two TabStrip.2 entries that you have
in your own manifest produced on your own machine and I can (of course) find
both of those IDs when I use RegEdit to search for them in the Registry on
my machine. The second TabStrip2 entry which appears in your own manifest
does not appear at all in the manifest produced on my machine, and when I
perform a RegEdit search for the second clsid
24B224E0-9545-4A2F-ABD5-86AA8A849385 it does not appear at all in my
Registry.
I wonder if you have somehow ended up with two copies of the ocx installed
and registered on your machine, perhaps one for one user and another for
another user or something like that, and if MMM is picking them both up? If
I search my Registry for the clsid 1EFB6596-857C-11D1-B16A-00C0F0283628 (the
one which we get in the MMM manifest on both our machines) it turns up about
three times in HKEY_CLASSES_ROOT and about the same number of times in
various keys in HKEY_CURRENT_USER and in HKEY_LOCAL_MACHINE and in
HKEY_USERS (I am the only User on this machine). However, when I search the
Registry for the clsid 24B224E0-9545-4A2F-ABD5-86AA8A849385 (the clsid which
turns up in your own MMM manifest but does not turn up in mine) then, as
expected, it is not found in the registry at all. What happens when you
search your own registry for those two entries. Presumably both of them will
show up in the various places I have mentioned. Perhaps you can draw some
clues from where they show up?
Also, if you do a normal full search for the file mscomctl.ocx, how many
copies of that file do you find on your machine, and do they all have the
same version numbers? Perhaps somehow two slightly different versions have
both managed to get themselves registered, perhaps to different users or
something? Then try the same thing for comctl32.ocx.
Mike