tags:

views:

1394

answers:

1

Hi,

I'm experimenting with writing ActiveX controls and noticed that I can't seem to create an ActiveX control in Visual Basic (6.0) which features slightly more sophisticated controls. Simple controls like labels, buttons and check boxes seem to work fine, but as soon as I try to add e.g. a tree control to my form, the ActiveX control stays entirely blank as soon as I embed it into some host application on another computer. It works fine on my development box though.

While going through the Projects->Components (Ctrl+T) list, I found two libraries which apparently contain a tree control:

  • Microsoft Windows Common Controls 5.0 (SP2)
  • Microsoft Windows Common Controls 6.0 (SP6)

As soon as I add any of the controls from these libraries to my form, the form stays entirely gray when embedded on another computer. The other computer is a Windows XP system, so I hoped that missing redistributables wouldn't be an issue, given how old Visual Basic 6 is. To be sure, I installed the VB6 redistributables, but unfortunately that didn't make a difference.

Does anybody know why my ActiveX control would stay gray on other computers, but not on mine, as soon as I add any of the controls from the above libraries to me form? FWIW I just need a tree control so if there is some other, more appropriate, library available - that's fine with me.

UPDATE: As it turned out, it helps to download MSCOMCTL.OCX into C:\WINDOWS\SYSTEM32 on the other computer and then registering it via regsvr32 C:\WINDOWS\SYSTEM32\MSCOMCTL.OCX. However, I didn't find an official source for this file, and running the COM registration by hand looks cumbersome to me. Is there really no redistributable I could use?

+3  A: 

VB6 runtime is preinstalled on XP and above but the Common Controls component you are referencing is not.

Try installing Microsoft Visual Basic 6.0 Common Controls redistributable on the client machines or event better make a setup for your application.

Edit:

Opps, the link is for an update that does not install the OCXs if not already present. The only redistributable I find is a merge module for Windows Installer.

wqw
Ah, interesting! Indeed, downloading 'mscomctl.ocx' into the XP machine and storing it in C:\WINDOWS\SYSTEM32 helped. I then needed to register the server (by running 'regsvr32 C:\WINDOWS\SYSTEM32\MSCOMCTL.OCX') and that made everything work. This is quite cumbersome though, is there really no easier way? :-/
Frerich Raabe
If you put the OCX in the same folder the EXE is run from, VB runtime will try to register it automagically (no regsvr32 needed). The other alternative is reg-free COM with Make My Manifest (http://mmm4vb6.atom5.com/) if you do not want a full-blown setup.
wqw
Don't put common OCX's into the app folder and allow them to self-reg when the VB6 program invokes them. This is where DLL Hell comes from. Create a proper installer for your appication that does version checking and maintains the usage count in the registry as you are supposed to. Or use MMM, but if you do you are responsible for servicing the dependencies as new versions are released (mostly for security reasons).
Bob Riemersma
+1 to Bob R for "Create a proper installer..." Not doing this accounts for 80% (stat made up on the spot) of the problems I see with COM errors 429 (ActiveX component can't create object) and 430 (Class does not support Automation or does notsupport expected interface). I see one of those, and ask the developer, "Did you create a setup package?" and the answer (80% of the time) is "No, we didn't think we would need it. It was just a small change to the main exe." The appropriate response at this point is "Well, *you* bought the ticket to DLL Hell. Why do you want *me* to take the trip?"
JeffK