MORE INFORMATION
Microsoft's comprehensive object strategy is built around the OLE object
model and is designed to provide developers with a consistent and open
standard for defining what an object is and how objects interact with one
another.
Benefits Associated with Microsoft OLE Custom Control Architecture
- OLE technology is now an integral part of custom controls, creating
a new open standard for component-based software development.
- You will have the ability to create either 16- or 32-bit custom
controls that have all the power of OLE 2.0 functions and services,
including Visual Editing, Drag and Drop, and OLE Automation.
- OLE Custom Controls will have a broader base of usability, because
they aren't limited to being used with Visual Basic as .VBX custom
controls are. OLE Custom Controls can be loaded by any container
that supports OLE 2.0.
- Both 16- and 32-bit components can be developed using the same OLE
Custom Control source code under Windows, Windows NT, and future
versions of the Windows operating system and eventually other
platforms as well.
- Control wizards in the OLE CDK will enable developers to easily build
OLE Custom Controls using the Microsoft Foundation Classes (MFC) and
will allow developers to migrate existing .VBX custom controls to the
OLE Custom Control architecture.
Contents and Availability of OLE CDK
The OLE CDK will include:
- 16- and 32-bit extensions to MFC version 2.5 to support controls.
- ControlWizard for creating an initial OLE Custom Control project or
porting an existing .VBX control to the new architecture.
- ClassWizard extended to support OLE Custom Controls.
- Test Container for verifying OLE Custom Controls
- Full on-line documentation
- Samples of OLE Custom Controls with source code.
The OLE CDK will be available:
- As an add-on product to Microsoft Visual C++ version 1.5, for creating
16-bit controls.
- As an add-on product to the next version of Microsoft Visual C++ for
creating 32-bit controls.
In addition, support for OLE Custom Controls will be included in future
versions of Microsoft development tool products and Microsoft Visual Basic,
Applications Edition, bringing OLE Custom Control capabilities to the
family of Microsoft Office business productivity programs.
Future of .VBX Custom Controls
To preserve existing customer code bases that use Visual Basic custom
controls, Microsoft will continue to support the current .VBX custom
control architecture with 16-bit versions of Visual Basic and Visual C++.
For 32-bit development, OLE Custom Controls will be the extensibility
mechanism of choice.
By merging the benefits of OLE 2.0 with the existing .VBX architecture,
Microsoft is offering independent software vendors and customers an open,
standard way to realize all the benefits of component-based software
development. For example, users will be able to plug different OLE Custom
Controls into a database or spreadsheet application to provide a range of
custom functions such as specialized financial modules, equation editing,
scientific analysis, run-time tutorials and charting. In the past, the
primary benefits of object-oriented programming were directed at
programmers; OLE brings the benefits of object technology to a broader
audience, including end users, developers and system integrators.
Questions & Answers
Q: Can I use OLE controls from other products such as Microsoft Access
version 2.0 in my Visual Basic version 3.0 program?
A: Yes. Because OLE custom controls are actually OLE 2.0 servers, they
can be embedded in any OLE 2.0-compliant application, including
existing released versions of Microsoft Excel, Visual Basic version
3.0 (using the OLE 2.0 container control), and many third-party
applications as well.
However, Microsoft Excel developers do not have access to OLE custom
controls Windows events such as mouse clicks. Microsoft Access version
2.0 will support OLE custom controls fully, including events.
The Microsoft Access Developers Kit (ADT) version 2.0 ships with
several OLE custom controls: calendar, scroll bar, and the Data View
control. The calendar and scroll bar can be embedded in any OLE 2.0
application, including a Visual Basic version 3.0 application, but the
Data View control can't because it is designed to run only with
Microsoft Access.
Q. How does licensing work with OLE custom controls?
A: Most OLE custom controls, like the calendar and scroll bar in the ADT,
work like .VBX controls. If the Data View custom control is used in a
Microsoft Access application, the end user must have a copy of
Microsoft Access installed on their computer. The OLE custom control
architecture allows for a lot of flexibility, so it is up to the
control creator to define the licensing restrictions for his or her
control. We expect most third-party OLE custom controls will have
licensing restrictions to the same extent as .VBX controls do today.
Q: Do I need to make modifications to my source code to run in the next
version of Visual Basic?
A: No. The next version of Visual Basic will be backwards compatible with
existing .VBX controls so that no modifications are necessary. Third-
party OLE controls that replace the .VBX controls will also be
backwards compatible. Check with the third-party supplier of your
existing .VBX controls about their plans for releasing OLE custom
control upgrades.
Q: Is it true that .VBX custom controls are not going to be supported in
the next version of Visual Basic?
A: No. The .VBX custom controls will still be supported in the next
version of both Visual Basic and Visual C++ (16 bit version). However,
all new 16- and 32-bit custom control development in the future will
be through the OLE Custom Control Development Kit.
Q: What tools is Microsoft providing to help me port my .VBX control to
OLE or to create OLE custom controls from scratch?
A: The new Control Development Kit (CDK) includes wizards, a VBX porting
tool, and documentation that specifically addresses porting a .VBX
control to the new architecture. We have found that getting a
preliminary working OLE custom control up and running can be
accomplished in a very short period of time. The Control Wizard, which
is part of the CDK, provides stock properties and events and creates a
working shell control from which the developer can customize and add
their own control-specific code and features.
Q: Is Microsoft offering a porting lab to help customers port VBX to OLE?
A: We are already working closely with the VBX ISV community, and our
preliminary experience with porting these controls has shown that a
porting lab will probably not be necessary because the process isn't
difficult. As we move forward, we will continue to monitor third-party
porting efforts, and we will assist them in every way we can.
Q: Is there any proof (benchmarks) on actual OLE custom controls that
they can be fast enough for use as components in shipping products?
How can my controls be as fast via OLE as they are via VBX?
A: A major design goal for the OLE custom controls architecture is high
performance and small footprint. We have done some preliminary tests
that show that OLE custom controls can, in some cases, be faster than
.VBX controls.
Q: What will this do to my business? I built a strong franchise around
.VBX controls.
A: Microsoft will continue to support .VBX controls under 16-bits in the
next revisions of Visual Basic and Visual C++, concurrent with support
for the OLE custom control architecture. We will continue to work with
control vendors to help them evolve from today's VBX standard to the
new OLE custom control standard for both 16- and 32-bit Windows
platforms. OLE custom controls offer new choices and greater
flexibility for customers, ultimately resulting in reduced development
time and decreased costs.
Q: Why not support .VBX controls on 32 bits for backward compatibility,
and support OLE too?
A: OLE is Microsoft's strategic direction for component-based software
development. OLE is a standard that is supported widely in the
software industry. Merging the benefits of OLE with the benefits of
.VBX custom controls will bring the best of both approaches together
in one, standard architecture. While .VBX custom controls have helped
make Visual Basic successful, they use a proprietary technology that
is tied to the 16-bit Windows architecture.
Q: What is the relationship between future Microsoft operating systems
and OLE custom controls?
A: OLE custom controls are an integral part of our future operating
systems. Much of our future operating system user interface will be
based on OLE custom controls.
Q: How many files and how big will the files be that I and my customers
must ship to build applications that use my OLE custom controls?
A: The controls and the architecture itself are still in development,
so it's too early to know exactly how big or how small the controls
will be. The maximum number of files a control developer must ship
with their application is two files -- one file for the control, the
second file for a control runtime DLL, which is shared across by
all OLE custom controls on the system. The standard OLE operating
system .DLL files must also reside on the computer. The whole concept
behind OLE and component development is to minimize the amount of
code on both the developer's and user's desktop, so you can be sure
that we are working to minimize the size of the files required for
OLE custom controls, as well as to maximize control performance.
Q: Can I maintain a single source code tree for both 16- and 32-bit
controls?
A: Yes. If you use the Microsoft Foundation Classes (MFC), one
source-tree can be compiled to create a 16- or 32-bit OLE custom
control.
Q: Do I have to use Microsoft Visual C++, the Control Development Kit,
and the Microsoft Foundation classes to create OLE custom controls?
A: No, but these tools make it much easier for developers to create OLE
custom controls.
Q: Some developers familiar with OLE have suggested that the overhead in
code is burdensome for a simple VBX-like object such as a push-button.
A: You will be surprised how little the overhead is with OLE custom
controls. OLE custom controls even allow you to include multiple OLE
custom controls in a single file, distributing the already minimal
overhead across multiple controls. This minimal overhead is a
worthwhile tradeoff, particularly for developers who want to take full
advantage of the portability that OLE provides. And developers who
will be working in 32-bit environments will want to get as much lead
time as possible to work with OLE custom controls, as it is the
control model we are supporting in 32-bit mode in all future versions
of our development tools.
Q: How can I be sure that OLE is the model I should be building my
software around? The VBX model has been such a success. How can I be
sure of the success of OLE?
A: OLE is Microsoft's strategic component object model. We have been
promoting OLE for the past 18 months. OLE is not new. It's no secret
in the industry that OLE is Microsoft's stated future direction. In
the past year, Microsoft has sponsored conferences and seminars that
have focused, in part or in total, on what OLE is, why it's important,
and how to work with it now and in the future.
Microsoft is not the only company endorsing and promoting OLE as an
industry standard for component-based software development. There will
be over 150 non-Microsoft OLE-compliant applications shipping by
Spring COMDEX 1994. 25,000 copies of Kraig Brockschmidt's book,
"Inside OLE 2.0" have been sold. And there are 8,000 developers
currently doing OLE development work.
Microsoft and our ISV community have made .VBX controls an industry
success story. We plan to build on that success by merging the
benefits of OLE with the benefits of .VBX custom controls to bring the
best of both approaches together in one, universal custom control
architecture.
Naturally, Microsoft will continue to support .VBX controls under 16
bits in the next revision of Visual Basic, concurrent with support for
the OLE custom control architecture. We will continue to work with
control vendors to help them evolve from today's VBX standard to the
new OLE custom control standard for both 16- and 32-bit Window
platforms.
Trademarks
Microsoft, Visual Basic, Win32, and MS-DOS are registered trademarks and
Windows, Visual C++, and Windows NT are trademarks of Microsoft
Corporation.
Macintosh is a registered trademark of Apple Computer, Inc. UNIX is a
registered trademark of UNIX System Laboratories, a wholly owned subsidiary
of Novell, Inc.