Automation Error - Third Party Control

[DSJ1967]

We have recently released a program that invokes a third party control inside of a custom control. The problem is that our client also released an application that used the same 3rd party control with the exception being that is was a slightly newer version. There installation of the 3rd Party control overwrote our version and caused an RTE in our program (Automation Error - Can't start control sort of message)

I guess that our program is looking for a specific instance of a control with a particular CLSID not finding it (as it has been overwritten with another) and bombing. One solution would obviously be to recompile and redistribute the application using the same version of the control but this won't prevent this problem from happening again.

In my mind, the program should be looking for the latest version of the control. Is this true? Does the CLSID get 'hard coded' into the compiled application? If so, is there anyway around this problem?

Thanks in advance

 

[JohnYingling]

A new GUID is generated every time unless the control is compiled with "binary compatibility". I believe Win 98 SE on up allow for "side by Side" execution of incompatible controls. Welcome to DLL hell. Is it possible to "late bind" to the control i.e. refer to it As Object rather than As xxxxxx. That way you only have to be compatible with the name and the names of the methods and properties of the control.

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript