Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations sizbut on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Project and Binary Compatability

Status
Not open for further replies.

Craftor

Programmer
Feb 1, 2001
420
NZ
Hi again all

I have made a user control and compiled it into an ocx (set with binary compatability). I added this onto a form in a different project and compiled that project (call it project 2). Now, I went back and changed the ocx, recompiled it and tried to run project 2 again and it came up with an error message that the ocx was not compatabile with the project - the incorrect version was being used. I recompiled project 2 and it worked fine. Should I rather have set my compatability on my ocx to project? Or do I just have to go the recompile route if I change my ocx?

Thanks a lot, everyone

Craftor

 
Craftor -

What I do is:

When I'm happy with the public interfaces I'm supplying, I compile my OCX (or DLL or ActiveX EXE), and copy it into a subdirectory called "Binary". I then go into my project and set binary compatability, pointing it at this binary program/module. That way, every time I recompile, I maintain compatability with this older version.

When it's time to release a new version, I do one last build and then copy this version over top of the one in the Binary directory. I then ship my control.

When you're writing code, and you get a message complaining about a change will break compatability -- undo your change! If you continue on, it will break compatability for your users, and they'll get the message you got.

Typically, changing a function name, changing a parameter list, deleting a function, etc. will cause compatability to break. If you run into a situation like this, leave the function prototype like it was, but put a error-return code into the body of the function. Move everything that function did into a new function, which you can modify all you want. You see, it's OK to add new functions. Just call them "MyFunctionEx" or something similar.

Chip H.
 
I have a similar problem and would like to know the proper procedure for making things connect. Here is the problem. I have a Main exe that uses another project that is compiled to a dll. The Main exe generates an error when it starts up and does a call to the dll. The error is something like cannot create the ActiveX component...
I have checked the reference and see that the Main exe has a reference to the dll and the dll has a reference to the Main exe. The paths are correct.
What is the proper order for compilation of these to get them to see each other?
What are the settings that need to be set in the main exe project and the dll project before compilation?
I am new to VB programming. This application was written by someone else and is no longer available for assistance.
The author wrote text in one of the classes of the dll project saying that changing public items would break the binary compatibility...

Any suggestions would be appreciated
 
You need to recompile the DLL before the EXE. It would be best if you were to set binary compatability on it (see my earlier reply to Craftor).

If you open a .vbp in notepad, you'll see the references that you have set in your project. The most important part about the reference is the long hexadecimal number, which is called a GUID. Stands for Globally Unique IDentifier. Every time you compile an ActiveX project (DLL, OCX, EXE) without binary compatability set, a new number is generated. With binary compatibility set, that number gets re-used and stays the same.

When your applications that have a reference to your project try and instantiate a copy, they use the GUID to try and find it in the registry. Without binary compatability set, it can't find it (because it now has a new GUID), and so you get an error.

The way around this is to use late binding (do a CreateObject on it), which uses the name of the project (the ProgID) and not the GUID. This has the side effect of making your code slower, as every time that object gets called the reference has to be re-checked.

Chip H.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top