Now that the possibilities have been outlined, let's look at some common situations and what the optimal compatibility setting is likely to be.
| A New Project | Without an existing type library to be compare with, binary compatibility is meaningless. By selecting Project Compatibility, you make it easier for other projects to include a reference to your component for use in early-binding. The reason for avoiding No Compatibility is that every time to restart your component's project, a new GUID is created. Other projects that refer to your component will then develop a missing reference (see the next page for an explanation |
| New Version of Existing Component | This is the situation that Binary Compatibility was designed to address. With this compatibility level, you can deploy your component without fear. Assuming that you follow the compatibility rules, of course. |
| New Version (No Backwards Compatibility) | Need to go back to the drawing board? Setting No Compatibility will ensure that previous clients of your object will not be able to use the newer verion. |
| Changing an Existing Method's Parameter List |
This is one of the more common situations. After deploying your application, you realize that an additional parameter is requlred for the enhancement you are developing. Or, to handle an unforeseen situation, one of your parameters needs to change a data type. Binary Compatibility is not possible in this situation. Unless you create another method (typically with a similar name) to perform the new functionality. For example, I might have a method called Add(A as Integer, B as Integer). For example, I might have a method called Add(A as Integer, B as Integer) As Integer. I'm betting that you can figure out what the method actually does. But, as my component becomes more advanced, I decide to add support for Floats as well as Integers to my function. If I change the data type (to Variants, for example), I could not use Binary Compatibility. So instead, I create another method called AddB that takes variants as parameters and performs its magic. I can continue to use Binary Compatibility (my class is still Version Compatible) and any existing programs will continue to function. The only drawback is that I need to make changes to the client programs to use the new method if I want to give them access to the new features. Unfortunately, that is the price for lack of foresight in the initial design. |
Comments