VB3 Intro to Microsoft OLE Custom Control Architecture, Tools

ID: Q113895

The information in this article applies to:

SUMMARY

Microsoft is introducing OLE Custom Controls that will combine the benefits of Visual Basic programming system custom controls (.VBX files) with the open standard of Object Linking and Embedding (OLE).

Microsoft also plans to offer a Control Developer's Kit (CDK) to make it easier to add OLE capabilities to existing .VBX custom controls, thus facilitating component-based software development for Windows-based applications. This article describes this new technology and explains the implications for users as well as control developers.


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

Contents and Availability of OLE CDK

The OLE CDK will include:
The OLE CDK will be available:
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.

Additional query words: 3.00 W_VBApp 3rd party 


Keywords          : kb3rdparty kbpolicy kbref IAPOLE 
Version           : 3.00
Platform          : WINDOWS 
Issue type        :

Last Reviewed: June 23, 1999