At the end of the second part of this tutorial, we encountered a small problem, but in exactly, it is actually a big problem. If there is time, this problem should be worth a big effort to study.
Remember how we encountered that problem? At that time, we compiled the ActiveX DLL first, then compiled the test programs that use the DLL. Next, we recompile the DLL because it is assumed that the contents in the DLL need to be modified. However, when running the test program, there is an error!
Although we can recompile the test program so that the program can run correctly. However, if this is not a VB program, but the Excel data sheet or the C statistical program is using the DLL, is it to recompile these programs every time you make a small modification for the ActiveX DLL?
Yes, it must not be like this.
Because experience tells us, this is a compatibility issue. So, you can do this:
Start Visual Basic to open the Northwind project;
Select "Project" -> "Northwind Properties" menu;
Click the "Component" tab;
Browse the page content of "Version Compatibility", you can find three options. Now explain:
No Compatibility - Each time you compile, the user COM component is labeled a new tag, which means that the program can only use the old tag (previous version) DLL.
Project Compatibility - User COM components are not always labeled with a new tag each time you compile. If so, any current application will fail. In fact, it will only be like this only when the current project and the compiled DLL project are different.
Binary Compatibility - Each time you compile, the application always tries to save the previous compiled DLL tag, which ensures that the application uses no blue screen crash. However, if the DLL that will be compiled and the previously compiled DLL is too large, the new tag will be marked.
Let's test the above arguments:
Open the test procedure in this tutorial;
Rebate it;
Try and run, you should work properly;
Open the ActiveX DLL project;
Set its properties to binary compatibility;
Rebate this DLL;
Test the test procedure should be able to work properly.
Ok, it seems to solve the problem. However, after recompiling the DLL, most developers will fall into another incompatible situation.
Is there a better solution? We temporarily put this problem on one side!
You can access the following site to get more content:
Www.pylonofthemonth.co.uk
