Visual Basic Tutorial Part 11

myitcareer.org-Your IT Career Partner For Life. Please Bookmark It.
Homework Help | Buy Book | Buy Phone | Top Web Hosts | Hire Web Designer
Home | Interview Questions And Answers | Hosting Charges | Online Tuition
Top Domain Registrars | Hire Freelancer | Employee Provident Fund | Hindi News

Changing the names, data types, or order of the

parameters of a public procedure or Property procedure
in a public class module or control.
·
Changing the Procedure ID (DispID) or other
parameters in the Procedure Attributes dialog box.
Time to Take Stock
When you've identified a necessary change that will
cause your component to be incompatible with earlier
versions, it's a good idea to take the time to
evaluate the entire set of interfaces, before plunging
ahead and creating an incompatible version of your
component.
Consider Multiple Interfaces
Remember that there are alternatives to using Version
Compatibility. Consider enhancing your component by
adding new interfaces with the Implements statement,
as described in "Providing Polymorphism by
Implementing Interfaces," in Chapter 6, "General
Principles of Component Design."Consider enhancing
your component by adding new interfaces with the
Implements statement, as described in "Providing
Polymorphism by Implementing Interfaces" in "General
Principles of Component Design."
Multiple interfaces, a key feature of the Component
Object Model (COM) -- on which the ActiveX
specification is based -- provide a more flexible way
to enhance software components. They allow you to
evolve your systems over time, without breaking
existing components.
You don't have to tackle the daunting task factoring
your existing class module interfaces into small
interfaces more suitable for use with Implements -- one
of the benefits of using multiple interfaces is that
you can start small, adding new interfaces to the
system only where new functionality is required.
Going Ahead with Incompatibility
If you decide to go ahead with an incompatible
version, you can minimize future problems for the
users of your component by concentrating in one
release all the changes you can anticipate that might
break compatibility again if they have to be made in
later releases.
In planning for an incompatible change, treat the
project as a fresh start. Devote as much care to
planning as you would if you were creating a brand new
component.
Creating an incompatible version requires three steps:
changing the project name, changing the file name, and
compiling with No Compatibility selected.
Changing the Project Name
The key change you must make, when you need to
distribute an incompatible version of your component,


is the project name. The project name, which is set on
the General tab of the Project Properties dialog box,
is the first part of the programmatic ID of each class
your component provides.
For example, the SmallMechanicals component might
provide a Widgets class. A client application would
create a variable to contain a reference to a Widget
object as follows:
Private wdgDriver As SmallMechanicals.Widget
The programmatic ID is the combination of project name
and class name, and it must be unique. If you create a
new version of this component, you might give it the
project name SmallMechanicals200. Both versions of the
Widget object could then be registered in the same
Windows Registry without confusion.
Changing the File Name
You must change the file name of an incompatible
component. If you use the old file name without
incrementing the file version number, the incompatible
component may not install on computers where the old
file exists. If you increment the file version, the
new file will over-write the old, and applications
that used the old version will fail.
Compiling with No Compatibility
Before you compile the incompatible component for the
first time, open the Project Properties dialog box
(accessible from the Project menu), select the
Component tab, then select No Compatibility in the
Version Compatibility box.
Do not omit this step. Compiling with No Compatibility
ensures that the new executable will not contain any
GUIDs (for example, class IDs or interface IDs) that
belong to the previous version. This is necessary for
applications that use the original version to continue
working correctly.
Tip After compiling once with No Compatibility,
switch to Project Compatibility to simplify your
development tasks.
Alternatives to Version-Incompatible Changes
If you prefer not to make the change to multiple
interfaces, as described above, you can take a similar
approach with classes.
That is, you can avoid changes that cause version
incompatibility by adding new objects, properties, and
methods, instead of changing existing ones. Existing
applications continue using the old methods and
objects, while developers of new applications can use
the new objects.
For example, you might discover that to take advantage
of enhancements to your General Ledger system, you
need to add a SubAccount parameter to several business
rules in your FinanceRules component.
If each rule is implemented as a method of the GL
object, you could avoid creating an incompatible
version of the component by adding a new object named
GL97. This object would have the same methods as the
GL object, but with a SubAccount parameter where

appropriate.
If you need to add new versions of existing methods to
an object, you can give the new methods the same name
with a version or sequence number added -- for example,
`Execute2.'
This approach is not as flexible or efficient as
implementing multiple interfaces. You may end up
replicating entire classes, and class interfaces may
become large and unwieldy -- for example, you might
find yourself using a Query class with an Execute
method, an Execute2 method, an Execute3 method, and so
on. However, it's a step in the right direction.
For More Information "Providing a Reference Point
for Binary Version Compatibility" describes when and
how to specify a version of your component as a
reference point for version compatibility. See
"Version Compatibility" for a list of topics related
to this feature. Software evolution using multiple
interfaces is discussed in "Providing Polymorphism by
Implementing Interfaces," in Chapter 6, "General
Principles of Component Design."Software evolution
using multiple interfaces is discussed in "Providing
Polymorphism by Implementing Interfaces," in "General
Principles of Component Design."

Send feedback to MSDN. Look here for MSDN Online
resources.
Version Compatibility in ActiveX Components

A component can be part of another application because
it provides Automation interfaces that the other
application can manipulate. Each public class module
has a default interface that includes all the
properties and methods you added to the class module,
plus any secondary interfaces implemented using the
Implements feature.
Once your component has been used in an application --
or, in the case of ActiveX controls, embedded in a
document or on a Web page -- you can change its
interfaces only at the risk of breaking the client
application.
Suppose, for example, that the Spin method of your
Widget object has one argument, Speed. If you
distribute a new version of your component, in which
you redefine the Spin method so that it also requires
a Direction argument, you could cause run-time errors
in existing applications.
At the same time, a successful component will
inevitably spark requests for enhancements. You will
want to provide new objects, or add new properties and
methods to existing objects. Occasionally you will
even want to change the arguments of existing methods
of existing objects.
The following topics describe the Version
Compatibility feature of Visual Basic, which is
designed to allow components to be enhanced without
causing existing applications to fail.

·
When Should I Use Version Compatibility? Describes
the Version Compatibility options and when to use
them. Describes an alternative technique for enhancing
software components.
·
Maintaining Binary Compatibility Describes the
versioning system Visual Basic uses to prevent
compatibility problems.
·
Levels of Binary Version Compatibility Describes
the degrees of binary compatibility Visual Basic
measures.
·
Providing a Reference Point for Binary Version
Compatibility Describes when and how to specify a
version of your component as a reference point for
version compatibility.
·
Using Binary Version Compatibility Describes when
and how to use the feature, problems you may
encounter, and messages you may get from Visual Basic.

For More Information See "Polymorphism, Interfaces,
Type Libraries, and GUIDs," in Chapter 6, "General
Principles of Component Design" for background
information and concepts.See "Polymorphism,
Interfaces, Type Libraries, and GUIDs" in "General
Principles of Component Design" for background
information and concepts.




Next topic
Previous topic