| Home | Previous Lesson: Opening from the nested storage Next Lesson: OCX Control Architecture |
As explained in the previous session, Traditional development tools and applications are monolithic, which means they come pre-packaged with a wide range of features, most of which can't be removed or replaced with alternatives. For example, both word processor and spreadsheet applications come with spell checker, charting, etc.. The functionality and interface might differ in these two applications, since these two applications are developed by different vendors/ developers. Component software overcomes these problems and also gives a lot more benefits.
A component is used by "plugging it into" a development tool container. The container and component are then used by an application developer together to create an application.
Component-based software development is a new and much more productive way to design, build, and sell software, and it has significant implications for software vendors, users, and corporations.
Advantages of Component Based Software and OLE 2.0
Choice of Component: Since component-based development enables the proliferation of a large number of standard components that work in a variety of containers from different vendors, corporations will have more choices of technology that can be tailored to meet highly specific business needs.
Better integration: Because development tool and application containers will support a standard means of component-level communication, products from different vendors will inter-operate more fully than today's applications. As a result, users will find it easier to exchange data between applications, and systems analysts will have an easier time building custom business solutions with off-the-shelf tools.
Better quality: Market opportunities for component developers will increase dramatically due to standardization. Broad-based participation in the component software market by small, medium, and large vendors will increase competition for discrete pieces of functionality. This increased competition should produce more innovative and higher-quality software.
Easier custom solutions: Component-based development will enable the same component to be easily plugged into a wide range of development tools and applications, allowing a much greater degree of application customization than is possible today.
Storage Requirement: Lot of monolithic applications provide common functionality such as spell-checking, monolithic software needs lot of storage requirements; In contrast, component software has a lot less storage requirement.
Custom controls were first defined in Microsoft Windows version 3.0. A custom control was a DLL that exported a defined set of functions. These controls were available from third-party developers. Custom controls were neat, but most C developers preferred to write their own. Moreover, the custom control architecture didn't support the Visual Basic development environment because it didn't allow Visual Basic to query the control for information on properties and methods. A new custom control architecture, called the VBX, was defined specifically to support Visual Basic.
Basically, a VBX is a dynamic-link library (DLL) that follows a specification, allowing it to work with Visual Basic. The VBX has become incredibly popular. Thousands of VBXes, from simple buttons to complicated networking controls, are available for a wide range of uses. VBXes are written in C/C++, so they can automate tasks that are too difficult, time-consuming, or simply impossible in Visual Basic.
VBX custom controls are currently one of the most popular forms of reusable software. The popularity of VBXes increased the demand for reusable components in other programming environments. For example, Visual Basic programmers needed custom controls for the 32-bit platform; and C/C++ users wanted controls for MIPS and Alpha as well as Intel processors. Unfortunately, VBXes are restricted to the 16-bit Visual Basic environment, so it was impossible to extend VBXes to answer these needs.
The VBX architecture, however, while it has been rapidly accepted by developers, was never designed to be an open, standard interface. The low-level interaction between VBXes and Visual Basic ties the VBX architecture to Visual Basic, making it a difficult interface for other container applications (other development tools) to fully support. Thus, the same VBX cannot be used across multiple hardware platforms, multiple operating system platforms, or in multiple development environments. It is also a 16-bit architecture that does not readily port to 32 bits.
Instead of extending a hardware-specific architecture (VBX) to support multiple platforms (especially 32-bit environments), the OCX Control (also called as OLE custom control) architecture was developed for both 32-bit and 16-bit platforms. In contrast, VBXes are limited to 16 bits.
OCX Controls are more powerful than VBXes and merge the benefits of VBXes with the benefits of OLE 2.0. They are not a superset of VBXes-they have a completely different architecture. Additionally, OCX Controls are not limited to Visual Basic. OCX Controls are designed to work in any container that supports OLE 2.0.
| Home | Previous Lesson: Opening from the nested storage Next Lesson: OCX Control Architecture |