ocx problems

I'm doing some maintenance programming on an application written by someone else (VB6). It uses the threed32 control.

When I initially loaded the project, I didn't have the control. After some searching, I found out how to install it from the VB6 CD and did so. I copied threed32.ocx from the \Common\Tools\VB\controls directory on my vb6 CD to my system32 directory, ran regsvr32 to register the file, and installed the registry entries included in that directory for licensing.

Everything worked fine.

Then one day, after I'd been on vacation for 3 weeks, I tried to open the project. No worky.

I've repeated all of the steps that made it work the 1st time around, to no avail. I still receive the "d:\winnt\system32\threed32.ocx could not be loaded" message. I can't open it in a new project either.

I've tried selecting the ocx from system32 directly by browsing, and I've also selected Sheridan 3D Controls from the components list. Same results.

The only thing I can think of that's happened since the last time it worked is that I installed several weeks worth of windows updates.

Any ideas?

It's possible that a dependancy DLL is missing...


goto the MSV6.0 tools in program files menu and select "depends" then browse to and open the threed32.OCX file. It will tell you what DLLS it depends on and you can check to see if they are all present and the correct version.

I seem to recall that the oca file for the control can cause this if it becomes corrupted, and removing it allows the system to recreate it. Try renaming the oca file for safety (while vb is not running), and see if that works.

Thanks for the responses.

I tried renaming the oca file (to ocd, humorously enough). Same error.

I opened up depends and looked at the ocx. I'm a little unclear on what all of the field mean, and which ones need to match exactly.

I've included a dependancy walker file in case you want to take a look at it, but here's an example of what I'm seeing:

Threed32.ocx depends on the following:
ADVAPI32, GDI32, KERNEL32, MFC40, MSVCIRT, MSVCRT, MSVCRT40, NTDLL, OLE32, OLEAUT32, RPCPRT4, USER32

and of course itself.

The dependancy walker file I sent is for the 2005 version of threed32.ocx. This is what was on my machine when it stopped working. I also have a 98 version, which comes on the VB cd. Neither works. Both seem to provide the same dependancy walker information at a glance, but I didn't meticulously verify every field.

Under the load order column, all the dlls are listed as "not loaded"

MFC40.dll has the following information in these columns:
File Ver 4.1.0.6140
Product Ver 4.1.0.1
Image Ver 4.1
Linker Ver 3.1
OS Ver 4.0
Subsystem Ver 4.0

File Ver and Product Ver match for most of the dlls. There are discrepancies for MFC40 and Threed32.ocx itself.
Threed32 is File Version 1.0.41.0 and Product Ver 1.0.0.0

All of the Link and Real Checksums match.

File and Link Time stamps are different for many of them: KERNEL32, MFC40, MSVCIRT, MSVCRT, MSVCRT40, NTDL, THREED32.OCX It seems that maybe these are not even supposed to match?

The Image, Linker, OS, and Subsystem versions are generally all over the map. These values do not match each other, and also generally do not match themselves for another file. (i.e. Linker version is not the same for threed32 as it is for kernel32, etc.)

Am I barking up the right tree here? How do I resolve these version discrepancies? - I'm a little wary of fiddling with an MFC dll. It's probably used by almost every app...

I don't have any experience at all with dll hell, if that's even my problem. Any help will be much appreciated.

I really don't have a definitive answer for you. The most obvious thing is the updates you mentioned. We've all heard about patches breaking things, so I would not be surprized if there's a relationship. I'm sure you've Googled around, though sometimes it takes many attempts to hit on the right keywords before you get an answer that fits.

Try putting the ocx file in the same directory where your application lies. The ocx files don't need to be registered if they are placed at the same path as your application.

You have to re-install you VB and then re-again do the all the copy procedure of your DLL ... it will be works again..

Regards!

I can't remember the last time I was so frustrated with anything.

I got up and running for a short while by installing VB6 on a different machine and using it, but it is time for me to make this work on my laptop again.

I have uninstalled some shareware software that had a more recent version of the control.

I have run a registry cleaner

I have searched for "threed" in my registry and deleted every entry that pertained to the threed32.ocx controls.

I have searched for the GUID for the TypeLib (the ID that is referenced in the VB6 .frm file) and deleted all of those entries

I have deleted threed32.oca

I have uninstalled and reinstalled vb6

I have copied the files from the VB6 CD, and I have run the vbctrls.reg to license them.

Attempting to add the control to a new project will register it, but still results in the "d:\winnt\system32\threed32.ocx could not be loaded." Error.

I feel like my options at this point are to rip this control out of my project on another machine so that I don't need it, or to reinstall the OS.

I really don't know what else to do, and I'm hoping that someone else has a solution that is less ridiculous/drastic. There must be a simple reason...

Does anyone know, perhaps, what the exact process VB6 uses to load a control is? i.e. read the GUID in the .prj file, look up the registry key, checks the version#, find the location, look for an oca, etc.

Perhaps if I understood what VB is looking for I could trace through manually and find what's missing/wrong.

Thanks,

Mish

It seems you may not actually need the ocx anyway, as I am reading it was discontinued as of VB5. The intrinsic controls now incorperate most of the functionality.

Take a look at this:
http://www.eggheadcafe.com/ng/micros...post265601.asp