How to Stay Compatible
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.