As if three levels of compatibility were not enough, Visual Basic also provides three levels of version compatibility. These are the compatibility rules referred to on the previous page.
Version Identical | Not surprisingly, this means that the interface between the two versions are identical. This situation might arise if you were implementing improvements to existing methods without exposing new methods to the world. |
Version Compatible | While properties and methods might have been added to the component, none of the existing properties or methods were modified (with respect to their interface). Again, the GUIDs are maintained and programs that run with the old version of the component should be none the worse for wear with the new module. |
Version Incompatible | At least one property or method that has been modified in this new version. Again, I'm talking about the data types or parameter lists, not the implementation. |
There is one caveat that I'd like to take a moment to discuss. If you have a procedure that gets deleted and then added back in again, you may think that you don't have to worry about the compatibility implications. Unfortunately, the order in which the properties/methods appear in the interface is one element that contributes to compatibility.
Geek Alert - When you compile a component, each property and method is assigned a Dispatch ID that is stored in the Type Library. The dispatch ID basically is a reference to a table entry containing the offset for the property/method. If you change the order of the for properties and methods in your code, you'll have the same GUID (technically, the interface hasn't changed), but the Dispatch IDs for the properties and methods will have changed. Any program that uses the early binding feature of your component without being recompiled will probably crash.
Comments