Windows 95, the most talked-about, written-about and sung-about—remember the Rolling Stones—PC operating system, is finally here. But is this OS really that much better than Windows 3.1? Sure, Windows 95 offers a better user interface, easier built-in networking and plug-and-play hardware configuration, but is it really going to make you more productive in the long run?
The answer is an emphatic yes! Windows 95 marks the first step toward real code sharing and reuse between widespread applications through a new technology called object linking and embedding (OLE).
OLE is a very broad term used to describe a wide variety of operations. However, all of these OLE terms come back to a simple concept—making different software components work together better.
OLE—What Does It Mean?
OLE, one of the most popular features in Windows 95, is also the one feature that confuses the most users. Most people associate OLE technology with the ability to embed an Excel chart within a Word document under Windows 95. But when you push all the marketing hype aside, OLE is the framework for Microsoft’s component object model, providing the infrastructure for different applications to communicate and share software components under Windows 95.
In some circles, OLE is described as “a better dynamic data exchange” because Windows 95 applications can be OLE servers or clients. This means that data or commands can be passed back and forth between each other.
OLE servers are applications that expose a portion of their functionality through a programmable command interface through OLE. OLE clients can pass commands to these servers to remotely control, or automate, their operations.
When client applications control OLE servers automatically, without any specific input from the end user, this is called OLE Automation. For example, when you double-click on an Excel chart embedded in a Word document, Word automatically sends the appropriate commands to Excel to take over the application menus and open up with the chart inserted. As the user, you simply see Excel “take over” your Word environment for editing the chart.
Development tools under Windows 95 will begin to offer OLE automation libraries with which you can write your own programs to send data to other applications. OLE automation will also send commands to these applications and remotely control them to operate on your data.
OLE Drag & Drop is another feature added to Windows 95 to simplify sharing data across different applications. Rather than use the clipboard to copy and paste data between applications, under Windows 95 you can simply drag objects or documents from one application to another. For example, you can drag Word documents and drop them onto your printer icon on the Windows 95 desktop to print them.
OLE Custom Controls
All these OLE features are nice if you are primarily working in Microsoft Word or Excel. However, as a scientist or engineer, you may not feel that convenience features add much to your daily development efforts.
The real productivity gains for system developers will come from OLE Custom Controls, a new architecture for packaging software components that can be reused in many different applications and development environments. OLE custom controls bring many of the same benefits to the table as object-oriented C++ programming without the front-end investment required.
C++ programmers have been claiming for years that C++ was the way to develop truly object-oriented, reusable code. C++ simply provides a foundation for you to design and build your own software objects.
Unfortunately, most developers, especially those in the scientific and engineering world, do not have the time or programming expertise to design and build their own C++ object framework from scratch. Even those who do have found that developing code to be truly reusable across different projects and between different programmers is an incredibly challenging task.
OLE controls are self-contained software components that can be plugged into many different development environments and configured or customized to fit a particular application. Instrumentation vendors can package data acquisition, analysis and display capabilities within OLE controls to give Visual Basic an engineering flavor.
Windows 95 Delivers
OLE controls are derived from the original Visual Basic custom control (VBX). When Microsoft introduced Visual Basic, they published the internal specification for building the controls used in Visual Basic. Third-party developers quickly caught on to the power and simplicity of Visual Basic as a Windows development tool and began delivering their own custom controls to add functionality to the standard Visual Basic development environment.
As VBXs quickly moved into new, uncharted territory, unforeseen technical limitations became apparent in the architecture. In addition, C programmers, seeing the growing library of VBXs, began looking for a similar set of tools.
Microsoft’s answer to the limitations of the VBX architecture is the OLE control. OLE controls are more powerful, more flexible 32-bit versions of VBXs that can be used in many different applications, not just Visual Basic.
The OLE control architecture is designed to make the controls easier to configure and program. Much of the software infrastructure that supports these new 32-bit OLE controls is built into Windows 95, a 32-bit operating system. Consequently, Visual Basic 4.0 and Visual C++ 4.0, both 32-bit development environments that support OLE controls, were released shortly after the launch of Windows 95.
The development of OLE controls as a standard software-object, or component, model is reaping tremendous benefits for both software vendors and users. With the more flexible architecture of OLE controls usable in many different applications, software vendors can deliver tools that are not limited to Visual Basic users only.
The more powerful 32-bit OLE control architecture allows developers to create more advanced controls that meet the needs of more and more vertical markets, expanding Visual Basic into more than just a data-base development tool. In fact, scientists and engineers now can use OLE controls developed specially for building virtual instruments. ComponentWorks from National Instruments is a new collection of 32-bit OLE controls for building virtual instruments in Visual Basic. ComponentWorks includes both user interface tools for creating virtual instrument front panels and data acquisition (DAQ) tools for controlling plug-in DAQ boards.
Developing Applications
OLE controls have properties, events and methods for configuration and programming. A property is a specific attribute or trait that you can set for a control. For example, the ComponentWorks slider control has a variety of properties that you can set to configure it, such as the maximum and minimum value of the slider scale, the color or the tick mark position.
A property for a control can be set either interactively or programmatically. When you are designing your interface in Visual Basic, you can right-click on the control and select Properties to view the control Property Pages. The property pages are intuitive dialog boxes with buttons, text boxes, selection lists and images that you can manipulate to set up your control.
You can also set properties in your Visual Basic source code to dynamically change the appearance or operation of your controls during program run time. This is very easy to do in Visual Basic. For example, to change the maximum value for your slider control to 20.0, you might use this line of code: slider1.maximum = 20.0.
OLE controls can also generate events when particular operations take place. Events act like a trigger to control the action of your program. For example, when you drag a cursor on a graph control or move the thumb on a slider control, an event is passed back to your Visual Basic source code so you can take appropriate action to respond.
Events can track very granular mouse operations for precise control over your program. For example, as you click down and drag the thumb up a slider control or change the position of a knob control, the OLE controls generate value change events. When you let up on the mouse button to commit to the new value of the slider or knob control, the OLE control generates a commit or mouse-up event.
As the program developer, you are free to perform different operations for each one of these events. You may wish to track the changes of a particular control in real time as you move the control and generate value change events, and then display a dialog once you finally let up on the mouse button to commit to a new control value.
Visual Basic automatically creates a different event callback routine for each event for which you wish to respond. As the program runs, Visual Basic automatically executes these different event routines as the events occur—hence the term event-driven programming.
And finally, the OLE controls can have a series of high-level methods, or functions, that you can invoke to set many properties at once and perform a particular operation. Methods can have parameters that you pass to perform complicated operations using the data or display capabilities of a particular control.
To put programming with OLE controls into perspective, let’s look at the ComponentWorks Graph control. Graph controls are very complex. You can set properties during design to configure the appearance of the graph, such as the colors, number of plots and axes operation (minimum and maximum values or autoscaling).
During program execution, the graph control can generate events when you drag cursors on the graph. For example, you can automatically display the X and Y coordinates of a cursor in the cursor event callback whenever you drag a cursor to a new position.
You can also use the Plot Y function to display an array of data to the graph control. OLE controls can bundle very powerful functionality into a very simple, easy-to-use programmable software object.
Test Software Development
As the father of OLE controls, Visual Basic has become the premier component-based development environment. Millions of data-base developers have adopted Visual Basic for building data-base front ends. And with the introduction of OLE controls, Visual Basic is being used in more application areas than ever before.
Even so, many engineers shied away from Visual Basic in the past because it was not fast enough. Since Visual Basic is an interpreted, rather than compiled, language, engineers feared that Visual Basic programs would not have the performance needed for high-speed, high-volume test situations. Although Visual Basic was praised as a good personal development tool, it was considered weak for the large-scale, team-based development projects found in many test software departments.
Visual Basic 4.0 addresses many of these issues. Although Visual Basic is not compiled, OLE controls are built in Visual C++ and delivered as 32-bit compiled C objects. As a result, the interpreted Visual Basic source code is simply acting as glue holding together a collection of high-performance compiled objects which are doing the majority of the work.
Visual Basic 4.0 now features an Enterprise Edition targeted at large-scale, team-programming projects. The Enterprise Edition includes an advanced source-code control and checkout environment integrated within Visual Basic.
And finally, Visual Basic’s roots as a data-base front-end tool is becoming more and more important in the test and measurement industry. Test engineers are increasingly looking for enterprise-wide integration between the data they collect on the factory floor and the off-line analysis and quality systems throughout their organization. What better way to integrate this information than with the premier data-base front-end connectivity tool?
Pick Your Favorite Container
OLE controls can be used in many different environments so, even if you feel that Visual Basic is not appropriate, you can still use OLE controls. You can use OLE controls in Microsoft Visual C++, Access, Visual FoxPro and Borland Delphi.
Although the number of applications in which you can use OLE controls is not very large today, this is a short-term problem. The specifications for creating OLE controls and OLE control container applications are being promoted by Microsoft. Although it is a very complicated and difficult process to support OLE controls within an application because of everything they can do, undoubtedly more and more applications will appear on the market in the next year or two.
The result of this standardization effort is that you are the big winner. You now can start new projects by shopping for low-cost, specialized software components that fit your needs. Once you find the components that will help you get your job done, you can select the development environment you are most comfortable using. BASIC users can use Visual Basic, C users can use Visual C++, and data-base users can use Access or FoxPro.
Can the Microsoft Office applications be far behind? On this topic, the development community will be split into two types of programmers. A smaller group of tool suppliers will be tasked with designing and delivering flexible, powerful OLE controls that work in many different environments. System developers will be able to pick and choose from these development tools to more quickly and easily construct complete systems for end users.
Software Component Challenges
Like any new technology, the move to a software component-based development strategy has many technical challenges. Any time you combine components from a variety of sources, there may be conflicts. As OLE control technology continues to evolve and companies gain more development expertise, stricter measures will emerge to enforce “well-behaved” controls.
Similarly, version control is a big challenge in component-based development. When you have 10 different programs using a particular control and the developer updates the control, how can you be sure that the new version will not break your old programs? This problem is compounded when you have hundreds of end users using these applications.
Instrumentation developers face some challenges as well. Moving to a component-based approach suggests conflicts for hardware resources. How do two different data acquisition controls access a single plug-in data acquisition board? How can they share different resources on a single board without interfering with each other? Will adding software component layers to your development approach add unnecessary overhead to critical high-speed applications?
These are all valid questions that will be answered as the software component industry matures. As more and more people adopt this strategy, developers will better understand and react to these performance and compatibility issues.
Conclusions
One of the single biggest concerns of the development community is code reuse. Scientists and engineers can be more productive by adopting a development strategy that lends itself to reusing code among products, programmers and development teams.
OLE custom controls provide a new architecture to deliver on these promises without requiring advanced C++ programming expertise. The simplified property-sheet interface and the flexibility of defined events and methods in OLE controls can provide substantial built-in functionality packaged in a format easily accessible from many different environments. The software development community is evolving toward the component-based approach: the OLE control architecture built into Windows 95 is a big step toward that goal.
About the Author
John Pasquarette is the Visual Development Tools Marketing Manager at National Instruments. He received a B.S. degree in electrical engineering from Texas A&M University. After spending a year as a consultant, Mr. Pasquarette joined National Instruments in 1990 as an Applications Engineer. National Instruments, 6504 Bridge Point Parkway, Austin, TX 78730-5039, (512) 794-0100.
VBX OLE Control
Architecture 16-bit 32-bit
Compatibility Visual Basic 1.0, 2.0 or 3.0 Any OLE Control Container
application, such as Visual
Basic 4.0, Visual C++ 4.0,
Access or Delphi
Configuration Standard Visual Basic Property Pages—tabbed dialog
property sheet interface pages with custom format,
(list of properties) input, images and color boxes
Programmability Limited set of predefined Control developers can define
methods (functions) for custom methods (functions)
each control for each control
Pass Data Values Pass data one point Pass entire arrays at once
at a time
Copyright 1996 Nelson Publishing Inc.
February 1996