Compatibility of Visual Basic com basic lectures

At the end of the second part of this tutorial, we encountered a small problem, but it is actually a big problem. If we have time, this problem should be worth our effort.

Remember how we encountered that problem? At that time, we first compiled ActiveX DLL and then compiled the test program using the DLL. Next, we re-compile the DLL, Which is because the content in the DLL needs to be modified. However, an error occurs when you run the test program again!
Although, we can re-compile the test program so that the program can run correctly. However, if this is not a VB program, but an Excel data table or a C ++ statistics program is using this DLL, do you need to re-compile these programs after every small modification to ActiveX DLL?

Yes, certainly not.

As experience tells us, this is a compatibility issue. Therefore, you can do this:

Start Visual Basic and open the northwind project;

Select the "project"-> "northwind properties" menu;

Click the "component" label;

You can browse the "version compatibility" page to find three options. Here is an explanation:

No compatibility -- at each compilation, the user COM component is marked with a new tag, which means that the program can only use the DLL of the old tag (Previous Version.

Project compatibility-at each compilation, the user COM component is not always labeled with a new tag. If yes, any currently used application will fail. In fact, this is true only when the current project is significantly different from the compiled DLL project.

Binary Compatibility-during each compilation, the application always tries to save the previously compiled DLL mark, so that the application will not experience a blue screen crash. However, if the DLL to be compiled is too different from the previously compiled DLL, the new mark will be marked.

Let's test the above arguments:

Open the test program in the previous part of this tutorial;

Recompile it;

It should work properly after trial run;

Open the ActiveX dll project;

Set its attribute to binary compatibility;

Recompile the DLL;

Run the test program and it should work properly.

Okay, it seems that the problem has been solved. However, after the DLL is re-compiled, most developers will fall into another incompatible situation.

Is there no better solution? We will temporarily put this problem aside!

You can visit the following sites for more information:

Www. pylonofthemonth. co. uk