Using ActiveX to Share Data Among Applications ActiveX automation lets you easily integrate several applications to create a unified data acquisition, analysis, and presentation system. Murali Parthasarathy, National Instruments

	MORE INFO
	SIDEBARs: ActiveX Glossary Distributed Data Acquisition with ActiveX

ActiveX, the Microsoft 32-bit standard built into Windows 95 and NT, has greatly simplified the way in which data can be shared among programs. This standard is similar to other interapplication communication protocols, such as Dynamic Data Exchange (DDE). However, unlike DDE, ActiveX automation provides a standard interface for this type of communications. Applications that use DDE do not always support all the data types defined by the DDE protocol, making it difficult to know whether the data from one application can work in another.

DDE is based on Windows messaging, which is inherently a single-platform technology. ActiveX, on the other hand, is becoming a multiplatform communications protocol (see the sidebar "ActiveX Glossary,"). Not only is it designed to function in the new 32-bit operating systems, but it has a greater capacity to evolve with technological advances than do some of the older standards. ActiveX automation provides a way of creating unified systems out of software components from different applications. This technology has become the leading standard by being powerful, efficient, and easy to use.

ActiveX also simplifies network communications. The standard passes data and commands among applications on one computer in the same way it performs the functions over a network, making network communications transparent to the user.

The format consists of two fundamental ideas: invoking methods and getting or setting properties. An application invokes methods on another application to control or perform some action in that application. For example, using ActiveX automation, a LabVIEW program can launch Excel and open an existing spreadsheet, invoking methods that Excel, as a server, exposes for automation (see the sidebar "Distributed Data Acquisition with ActiveX"). Usually, objects in applications also have methods accessible to other applications. For instance, after the LabVIEW program opens the spreadsheet, it can create rows and columns of data in the spreadsheet.

In addition to invoking methods, applications can also get and set properties in other applications or application objects. Properties include a variety of attributes of the application, such as setup options, colors, and titles. An example of one application setting properties in another is a Visual Basic program controlling the setup options of a LabVIEW virtual instrument (VI), such as turning off scroll bars, checking whether debugging is on, and setting the title of the VI. Methods and properties keep ActiveX automation simple by limiting the number of commands a user must understand, yet powerful by ensuring the flexibility of those commands through the variety of options they offer.

Figure 1. An ActiveX automation server exposes methods and properties controllable by an automation client. For example, a client application can invoke a method on the server, such as opening a new document or application. The client application can also obtain attributes of a server application by requesting properties, such as title names and colors.

The automation client application initiates the connection to a waiting server application. The client requests a connection and sends commands to the server to transfer data, change parameters, and run tests, as well as other controlling mechanisms.

The automation server exposes methods and properties for the client to control and read (see Figure 1). Although the command set is brief and simple, it retains enormous flexibility for one application to control another. All commands are defined in terms of methods or properties. Once you understand this short command set, you can apply it to any combination of applications, methods, and properties using the ActiveX automation standard.

Some of the common concerns that automation addresses are the ease of transferring data among applications, the need to reuse previously developed software that has the ability to include ActiveX, and the importance of a single integrated environment for the end user.

Automation avoids these delays by transferring data without the intermediate state. Using automation, a client program is able to launch a server application and send data (e.g., the values for the rows and columns of a spreadsheet) to the appropriate object in the server. Or just as easily, a client application can read data from the correct object in the server (see Screen 1).

Screen 1. This example shows a LabVIEW client program reading a cell value from a Microsoft Excel server. LabVIEW opens a worksheet, requests a specific cell location by invoking the Excel range method, and then reads the cell value by getting the Excel value property.

In some development environments, you must enter the correct method name, which can be found with an object browser. In Visual Basic, as long as you know the beginning of the method name, the environment attempts to complete your line of code for you. In LabVIEW graphical programming, you wire the name of your server application to a method node, and a pop-up menu containing all the appropriate methods appears automatically. You then select the method or methods you need from the menu (see Screen 2).

Screen 2. This example shows LabVIEW communicating control to a Web browser through an ActiveX method. All the appropriate methods for the Web browser are displayed from a selectable pop-up menu, so you can easily choose the method you need. Properties are likewise accessed through a selectable pop-up menu in LabVIEW.

You can get and set properties of other applications in the same way you invoke methods. In Visual Basic and other text-based languages, you simply type in the property and the value you need to get or set. In LabVIEW, you select them from the pop-up menu.

For example, a Visual Basic application can launch LabVIEW, execute the appropriate DA program, and then extract the LabVIEW data for immediate use in Visual Basic and Access. The only code added to the Visual Basic program is a few lines to invoke methods in LabVIEW to run the acquisition and extract the data (see Listing 1). With ActiveX automation, you can reuse ActiveX-enabled software and control it from a single application with minimal adjustments to your system.

Listing 1 Visual Basic Code The lines highlighted in red are ActiveX automation calls to LabVIEW. Dim lvapp As Object Dim vi As Object Dim paramNames(4), paramVals(4) Set lvapp = CreateObject("LabVIEW.Application") viPath = lvapp.AppDir + "\examples\apps\freqresp.llb\Frequency Response.vi" Set vi = lvapp.GetVIReference(viPath) 'Load the vi into memory vi.FPWinOpen = True 'Open front panel paramNames(0) = "Amplitude" paramNames(1) = "Number of Steps" paramNames(2) = "Low Frequency" paramNames(3) = "High Frequency" paramNames(4) = "Response Graph" 'initialize input values to the vi paramVals(0) = cwnAmplitude 'Amplitude value obtained from cell (4,5) paramVals(1) = cwnNumSteps '# steps value obtained from cell (5,5) paramVals(2) = cwnLowFreq 'Low Frequency value obtained from cell (6,5) paramVals(3) = cwnHighFreq 'High Frequency value obtained from cell (7,5) ' paramVals(4) will contain the value of Response Graph after running the vi. 'run the vi Call vi.Call(paramNames, paramVals)

By using ActiveX automation, you can control and communicate with other applications without any preparation by the operator (e.g., opening the right files or running the applications in a particular order). You can give your application a unified look, displaying the right interface to your end user at the appropriate times. By presenting a single environment, you minimize the effort that a user spends on the mechanics of the system, allowing the focus to be on the application itself. This increases the efficiency of both the user and your application and reduces the chance of introducing errors during manual steps that were previously necessary.

As industries increasingly demand more modular and flexible software, standard communications technology becomes even more important. Companies with libraries of developed code will enforce software reuse and integration to satisfy economic concerns and to improve efficiency.

However, as computer technology keeps evolving at a rapid pace, developers cannot immediately incorporate every new feature available in the industry. They need tools to keep abreast of the trends and choose the right technologies to help them do their job better.

To efficiently maintain your technical edge, make sure you choose reliable software that is flexible enough to evolve with important technology so that you can leverage software development immediately in your applications. With such software packages as Visual Basic, Visual C++, LabVIEW, and other fully functional ActiveX development environments, you can fulfill the demands of your industry without spending more time than you have to spare.

Home | Contact Us | Advertise © 2009 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.