Reg-Free-COM not quite working with TreeView and DatePicker

[wgcs]

I have tried using MMM and Visual Studio 2008 to generate a .MANIFEST file to "reg-free-com"-consume the MSCOMCTL.OCX and MSCOMCT2.OCX activex libraries.

Specifically, I'm using the TreeView and DateTimePicker controls.

On Vista, it almost works correctly: The tree populates via code and displays correctly, and the datetimepicker properly displays the date that is assigned via code.

However, both controls are then completely unresponsive to the mouse... click all I like, and nothing happens.

If I just run "REGSVR32 MSCOMCTL.OCX" and "REGSVR32 MSCOMCT2.OCX", then they both work perfectly!

Does anyone know what's wrong with my .MANIFEST?
Here it is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="GTWIN.EXE" processorArchitecture="X86" type="win32" version="15.00.38.0" />
  
  <file name="mscomctl.ocx">
    <typelib tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" version="2.0" flags="CONTROL,HASDISKIMAGE" helpdir="" />
    <comClass clsid="{1EFB6596-857C-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.TabStrip" description="Microsoft TabStrip Control">
      <progid>MSComctlLib.TabStrip.2</progid>
    </comClass>
    <comClass clsid="{66833FE6-8583-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.Toolbar" description="Microsoft Toolbar Control">
      <progid>MSComctlLib.Toolbar.2</progid>
    </comClass>
    <comClass clsid="{8E3867A3-8586-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.SBarCtrl" description="Microsoft StatusBar Control">
      <progid>MSComctlLib.SBarCtrl.2</progid>
    </comClass>
    <comClass clsid="{35053A22-8589-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.ProgCtrl" description="Microsoft ProgressBar Control">
      <progid>MSComctlLib.ProgCtrl.2</progid>
    </comClass>
    <comClass clsid="{C74190B6-8589-11D1-B16A-00C0F0283628}" 
              tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" 
              threadingModel="Apartment" 
              progid="MSComctlLib.TreeCtrl" 
              description="Displays a hierarchical list of Node objects, each of which consists of a label and an optional bitmap."
              miscStatus="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,setclientsitefirst"
              >
      <progid>MSComctlLib.TreeCtrl.2</progid>
    </comClass>
    <comClass clsid="{BDD1F04B-858B-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.ListViewCtrl" description="Displays a collection of ListItems such as files or folders.">
      <progid>MSComctlLib.ListViewCtrl.2</progid>
    </comClass>
    <comClass clsid="{2C247F23-8591-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.ImageListCtrl" description="Contains a collection of ListImage objects, each of which can be referred to by its index or key">
      <progid>MSComctlLib.ImageListCtrl.2</progid>
    </comClass>
    <comClass clsid="{F08DF954-8592-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.Slider" description="A calibrated control with a slider for setting or selecting values.">
      <progid>MSComctlLib.Slider.2</progid>
    </comClass>
    <comClass clsid="{DD9DA666-8594-11D1-B16A-00C0F0283628}" tlbid="{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComctlLib.ImageComboCtl" description="Microsoft ImageComboBox Control">
      <progid>MSComctlLib.ImageComboCtl.2</progid>
    </comClass>
  </file>
  <file name="MSCOMCT2.OCX">
    <typelib tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" version="2.0" flags="CONTROL,HASDISKIMAGE" helpdir="" />
    <comClass clsid="{B09DE715-87C1-11D1-8BE3-0000F8754DA1}" tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComCtl2.Animation" description="Animation Control">
      <progid>MSComCtl2.Animation.2</progid>
    </comClass>
    <comClass clsid="{603C7E80-87C2-11D1-8BE3-0000F8754DA1}" tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComCtl2.UpDown" description="UpDown Control">
      <progid>MSComCtl2.UpDown.2</progid>
    </comClass>
    <comClass clsid="{232E456A-87C3-11D1-8BE3-0000F8754DA1}" 
              tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComCtl2.MonthView" description="Microsoft MonthView Control" miscStatus="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,setclientsitefirst">
      <progid>MSComCtl2.MonthView.2</progid>
    </comClass>
    <comClass clsid="{20DD1B9E-87C4-11D1-8BE3-0000F8754DA1}" 
              tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" 
              threadingModel="Apartment" 
              progid="MSComCtl2.DTPicker" 
              description="Microsoft Date and Time Picker Control" 
              miscStatus="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,setclientsitefirst"
              >
      <progid>MSComCtl2.DTPicker.2</progid>
    </comClass>
    <comClass clsid="{FE38753A-44A3-11D1-B5B7-0000C09000C4}" tlbid="{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}" threadingModel="Apartment" progid="MSComCtl2.FlatScrollBar" description="Microsoft Flat Scrollbar Control">
      <progid>MSComCtl2.FlatScrollBar.2</progid>
    </comClass>
  </file>
  
</assembly>

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[dilettante]

I know this is an ancient thread but I had to check it out.

I created a small program using both of these controls, then compiled it and ran MMM 0.6.5 to create the manifest. It seems to work fine in both Vista (SP1) and XP (SP3).

You seem to have a version-independent progId attribute in your comClass elements, and then a version-specific progId as the content of a progId child element within the comClass. MMM doesn't do this but it is perfectly legal of course.

I don't see the problem with your manifest. Did you ever resolve this issue?

 

[wgcs]

Hi Dilettante,

Thanks for looking at it... I don't consider it an ancient thread, particularly since no one ever posted any ideas!

I eventually gave up on .MANIFEST files as "broken" (that is, as requiring the special magic that happens within Visual Studio for creating them... alot of help to anyone trying to do use manifests without VisStudio)

I instead did something crazy, but which works reliably (and which I carefully crafted in order to solve all my problems):
#1: the problem is that we ship several applications that use the same ActiveX controls. We have found that after installing one application, then installing another, any time the user goes and runs the first, Windows Installer pops up (sometimes for many seconds) to "Repair" the installation, because the 2nd install had changed the ActiveX registration. If we could use .MANIFESTs to be able to run without the regististrations, then they couldn't "fight" over the registrations.

So, our installations now are constructed like this:
1) I created a small InstallShield package that just installs and registers the ActiveX controls. Each of our applications call this installer. this installer is not supposed to do anything if it had already installed (that is, if it finds a particular file in a specific spot). However:

2) That installer (built with InstallShield Express v4) ignores all the "conditions" and always installs. So, I created a .BAT file that searches for the file, and can run the installer if the file doesn't exist. (Don't worry, the file is version-dependent so we can release an upgraded ActiveX package which would replace this current version.)

3) However, the InstallShield-built SETUP.EXE has trouble launching the .BAT file. (I tried launching CMD.EXE or COMMAND.COM with the .BAT as a parameter, too: no-go) In comes PackageForTheWeb (v3) which does successfully run a batch fle.

So, what we've got is 4 different InstallShield Express application installers, each calls a PackageForTheWeb .EXE file, which then runs a batch file that decides whether to launch the InstallShield Express-built ActiveX installer.

It's been much more stable then the ActiveX control registrations ever had been before, and much easier to get to work than .MANIFEST files.

(As for the version dependent/independent values, here's a few things about why they're like that:
1) It's been a long time, so I don't remember if MMM generated them that way or not. I think you're right, that it did not.
2) I have read ALOT about .MANIFEST files, and it seems that the (very obtuse and scarce) documentation indicates that this is really how it is supposed to be, since many programs would reference the version-independent ProgID, the Manifest helps to translate that to the version-dependent ProgID
3) Thinking about it, it just makes sense: If any ProgID was specified in a value in the key name, why would there be ANY need to repeat that value in a sub-key's contents? That violates database normal forms, and adds no new information to the file.
4) I tried it every way imaginable: Version dependent ProgID in both spots; Version independent ProgID in both spots; Vers-dep-ID in the Key and Indp-ID in the value; Vers-indp-ID in the Key, Vers-Dep-ID in the value...

... not a single one of them worked right.

It all was very frustrating, and since the public documentation about .Manifest files is sparse and vague, I worried that it might be like the HTML-Help Collection system that MS used for some MSDN Library shipments... it worked well, and let me compound several CHM files into one unified help system, but with HTMLHelp updates, MS broke the old system. (HTML Help Collections, too, were very poorly documented).

I'm fairly sad that you weren't able to reproduce the problem... I've had it on at least 2 computers. The .MANIFEST file would certainly be a more elegant way to solve the problem, and would allow our software to "play well with others".

First priority, of course, is to work, and second is to play well with our own other applications.

Thanks for your investigating the problem.. if you have any other suggestions, I'd appreciate ideas. (Though, unless Windows 7 causes some problem with our current system, I'm not inclined to change it.)

- Bill

Get the best answers to your questions -- See FAQ481-4875.