[RESOLVED] Multiple control OCX giving version trouble despite using Binary Compatibility

I have an ocx, let's call it IHateThisThing.ocx, and inside are 2 user controls: ThisOneSucks.ctl and Golden.ctl.

Someone else wrote this originally, but I needed to make a change to Golden.ctl. I needed to change one "InStr" to "InStrRev" and that was it. Done, no problem. Compiled great, using Binary Compatibility matched to the existing ocx that is in production, deployed it and it worked. The problem, however, is when someone tries to do anything that uses ThisOneSucks.ctl, they now get an error message that says "Failed to activate control 'VB.UserControl'. This control may be incompatible with your application. Make sure you are using the version of the control the was provided with your application." To clarify, it does actually say "VB.UserControl" and not "IHateThisThing.ThisOneSucks" as I would expect.

The two things I made sure happened are:
1. Used Binary Compatibility and no warning message was displayed
2. Checked the .VBL file that was generated when the ocx was compiled, the ClsID and the license matched the previous build

I took these same steps when I updated ThingsAreGood.ocx, EverythingIsFine.ocx, and GreatSuccess.ocx, but they only had 1 user control inside. I haven't updated any others that have more than 1 user control so I don't know if it's specific to ThisOneSucks.ctl or if the problem stems from having multiple controls.

I assumed that using Binary Compatibility should have prevented this from happening. In the main project, the controls are used via CreateObject and are not referenced (late binding).

I'm hoping to not need to restart the "compatibility trail" because the main project has the license string hardcoded. I inherited this project from someone that left the company and the production executable is older than the code last checked into SourceSafe so we don't even know what code is compiled into the executable. We're also working on a rewrite so we don't want to spend too much time on the current production version but we do need to be able to push out this change for IHateThisThing.ocx. I do plan to create a setup package and try un/reinstalling over the next 5 days our building is closed, but I don't expect anything to come from that. The posts I've read on the internet for the past week of searching have all said to re-register the ocx (done), reinstall (doing in the next 5 days), and reset the compatibility and start from scratch (can of worms due to main executable).

Any additional advice is appreciated.

I'm not exactly a guru concerning this but just a week or so ago a co-worker broke binary compatibility on a few modules linked together and rather than just rebuild everything I just went into the .vbp in NotePad and set them all to match. I mention this because I needed to use OleView.Exe to see the values and maybe you could check them against each other in your situation. It was here for me "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\OleView.Exe".

If I had to guess I would suspect that you didn't completely unregister the old OCX before trying to replace it with the new OCX.

I suspect that the registered typelib has interface versions that do not match the versions in the new OCX. You don't normally have a lot of control over this, these are not the file versions of the OCX itself.

Short term fix might be to have the old OCX in place and unregister it. Then replace it with the new OCX and register that. Otherwise you might have to clean the registry up manually which can be quite a chore to do thoroughly.


One way to avoid this, though it may be too late for you now, is to go to Additional Visual Basic 5.0 & 6.0 Samples and get:

Quote:

---

Binary Compatibility Add-in

This download includes the document "Revised Binary Compatibility" as well as the Add-in SyncCompt.dll. Binary Compatibility as implemented in Visual Basic 5.0 and Visual Basic 6.0 ensures that new versions of shipping products are fully compatible with older versions. The document explains issues around Binary Compatibility and GUID revision and introduces the DLL. The DLL add-in builds a new compatibility file to stabilize your product (except Standard EXE's which do not have binary compatibility). This tool only works in an Microsoft Windows NT® environment.

---

The included document can explain some of the issues.

To clean up the registry from unwanted/unavailable components you can RegDllView from Nirsoft
http://www.nirsoft.net/utils/registered_dll_view.html

Quote:

---

Originally Posted by TysonLPrice

I'm not exactly a guru concerning this but just a week or so ago a co-worker broke binary compatibility on a few modules linked together and rather than just rebuild everything I just went into the .vbp in NotePad and set them all to match. I mention this because I needed to use OleView.Exe to see the values and maybe you could check them against each other in your situation. It was here for me "C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\OleView.Exe".

---

Doesn't apply, see:

Quote:

---

Originally Posted by sdouble_2

In the main project, the controls are used via CreateObject and are not referenced (late binding).

---

I have figured out the problem. It wasn't as difficult as I made it out to be and was a bit silly.

These are the steps I took:
1. Compiled main executable to test with on my machine. Tried it, received same error as in first post.
2. Changed the license key in Licenses.Add for IHateThisThing.ThisOneSucks and recompiled main executable.
3. Ran main exe, new error: "No design-time license found for control 'IHateThisThing.ThisOneSucks'. Contact the vendor...."
4. Changed the license key back to what it was supposed to be and tried it all over again, back to the same error in from the first post. This made me look into the control's project a bit more. I found that it referenced another custom control itself that was a later version than what was installed on the production computers.
5. Changed the reference to TheOtherControl.OCX to the same version that was deployed and in production, recompiled IHateThisThing.OCX and everything was good.

So, what I learned is that VB6 wasn't able to follow the breadcrumbs to the other control and give me an error that mentioned "TheOtherControl.SomeInterface" and instead gave me a generic "VB.UserControl" error message. Maybe if IHateThisThing.OCX was actually referenced in the project, it would have been able to do so. Because of that, "VB.UserControl" tends to mean something outside of the immediate scope.