Talking to Other Programs and Objects

Whether you are on Mac OS X, Linux, or Windows, LabVIEW has tools that will help you communicate with other applications and objects on those systems. On Windows, there is support for .Net and ActiveX; on Mac OS X, there is support for Apple Events and pipes; and on Linux, there is support for pipes. We will now learn all about these exciting technologies!

.NET and ActiveX

.NET and ActiveX are frameworks from Microsoft that allow Windows applications to communicate with one another and to embed user interface components from one application into another. For example, with ActiveX, you can embed a Microsoft Excel spreadsheet into a Microsoft Word document (this used to be called OLE).

In order to use the .NET functions and controls in LabVIEW, you will need to have .NET Framework 1.1 Service Pack 1 or later installed. You can find out more information about these requirements in the LabVIEW Release Notes. You can download the .NET Framework from Microsoftit should be easy to find, using your favorite search engine or by searching the microsoft.com web site.

You should, however, be able to use the ActiveX functions and controls without installing any additional software.

.NET and ActiveX are very broad topics, and we'll only point you to a few things LabVIEW can do with them. Needless to say, only LabVIEW for Windows supports .NET and ActiveX, because they are Windows protocols.

The .NET and ActiveX technologies supported by LabVIEW are grouped into two main categories: Servers and Controls. A server is an application that runs outside of LabVIEW, and a control is a component that we will place on the front panel of a LabVIEW VI (for example, a LabVIEW front panel can contain a Microsoft Excel worksheet).

The .NET and ActiveX functions palettes (shown in Figures 16.30 and 16.31) are found beneath the Connectivity category of the Functions palette.

Figure 16.30. .NET palette

Figure 16.31. ActiveX palette

Communicating with .NET and ActiveX Servers

The functions in the following table allow you to open and close references to .NET and ActiveX servers.

(.NET) Constructor Node (Connectivity>>.NET palette) creates an instance of a .NET object. Double-click this node (or choose Select Constructor from its pop-up menu) to display the Select .NET Constructor dialog box and choose a .NET Assembly (see Figure 16.32).

Figure 16.32. (.NET) Constructor Node

(ActiveX) Automation Open (Connectivity>>ActiveX palette) opens an automation refnum that points to a specific ActiveX object. Select the ActiveX class by wiring an automation refnum constant or control to the Automation Refnum input. The refnum can be configured by choosing Select ActiveX Class>>Browse from its pop-up menu (see Figure 16.33).

Figure 16.33. (ActiveX) Automation Open

The Close Reference function closes .NET and ActiveX server references opened with the preceding functions. It may be found on the Connectivity>>ActiveX, Connectivity>>.NET, and Programming>>Application Control palettes (see Figure 16.34).

Figure 16.34. Close Reference

Once you have obtained a reference to a .NET or ActiveX server using the aforementioned functions, you can use the Property Node, Invoke Node, and Register Event Callback functions to read and write properties, call methods, and register for events (respectively).

Embedding .NET and ActiveX Controls on the Front Panel

One very useful way to use .NET and ActiveX in LabVIEW is to take advantage of the .NET Container and ActiveX Container (found on the .NET & ActiveX subpalette of the Controls palette, shown in Figure 16.35). These allow you to embed objects or documents from one application into another.

Figure 16.35. The .NET & ActiveX palette

The .NET & ActiveX palette also includes several containers that have been preconfigured for certain controls such as the Month Calendar, Web Browser, and Windows Media Player. Figure 16.36 shows a front panel where we have placed Month Calendar and Windows Media Player controls from the .NET & ActiveX palette.

Figure 16.36. .NET & ActiveX controls on a VI front panel

Once you have placed a .NET Container or ActiveX Container onto the front panel, you can insert a control by selecting Insert .NET Control or Insert ActiveX Object (respectively) from its pop-up menu. This will present you with a dialog for the desired control.

On the block diagram, the .NET Container and ActiveX Container terminals output a reference that can be wired to the Property Node, Invoke Node, and Register Event Callback functions to read and write properties, call methods, and register for events (respectively).

You do not need to explicitly open or close references to .NET or ActiveX controls. Just use the reference that flows out of the .NET Container or ActiveX Container terminal on the block diagram.

Do the following activity to see how you can embed a web browser on your front panel.

Activity 16-3: Embedding an ActiveX Web Browser in a VI (Windows Only)

In this activity you will embed a web browser ActiveX control in a VI's front panel.

1.	Open a new VI in LabVIEW. From the Controls>>.NET & ActiveX palette, select the ActiveX Container object (see Figure 16.37). Resize it to be very large on your front panel. Do not select the Web Browser object. This activity is going to demonstrate how to configure the ActiveX Container object yourself, rather than using a preconfigured ActiveX Container. Figure 16.37. ActiveX Container control found on the .NET & ActiveX palette
2.	Pop up in the container and select Insert ActiveX object. From the Select ActiveX Object dialog box, select Create Control. A list of all available objects is displayed. Next, scroll through the list, select the Microsoft Web Browser control, and press the "OK" button.
3.	Switch to the block diagram. You can now use automation functions with this refnum. Use the Invoke Node function from the Communications>> ActiveX palette. Once you wire the automation reference of the control container to the Invoke Node function, it will display the automation object (IwebBrowser2) it is accessing. You now can select from a list of methods it exposes by popping up on the Method terminal. Select the "Navigate" method (see Figure 16.38). Figure 16.38. An Invoke Node shown on the ActiveX palette and on the block diagram configured to call the Navigate method of the IwebBrowser2 automation object
4.	Pop up on the URL input and select Create Control. This will give you a string input for typing the URL you want to connect to.
5.	Return to the front panel, type in a URL, and run the VI. You will see the web page appear in the container. In Figure 16.39, we typed http://jeffreytravis.com. Figure 16.39. Your VI's front panel after you type in a URL and run the VI

Unless you already understand ActiveX, this example may seem like a little magic. How is it possible to have a web browser as a LabVIEW front panel control? The answer is that the web browser is not really part of LabVIEW; in fact, LabVIEW is doing very little. Instead, the fact that both LabVIEW and Microsoft Internet Explorer (IE) can communicate via ActiveX allows you to embed the IE browser into LabVIEW.

Note several things about using this ActiveX web browser control:

• It is very easy to use and set up with minimal block diagram programming.

• You have access to many other web browser properties and methods, such as resizing the browser, moving forward and backward, refreshing the web screen, and so on.

• You can easily and quickly access both static HTML documents (via the file:// URL) and Internet web sites (via the http:// URL) from LabVIEW.

• This will only work on LabVIEW for Windows; it is not available for other platforms

This type of example is great for an application where you wish to link to an online web-based help system, for example.

You'll notice that the .NET and ActiveX functions are very similar to the VI Server functions; so if you understand the VI Server, you should have no problem using the .NET and ActiveX functions. The main difference is that you will need to understand the methods and properties of the external .NET or ActiveX object (because LabVIEW can't know how it works). Many .NET and ActiveX components include a help file for the objects, which you can reference if it's available.

LabVIEW as an ActiveX Automation Server

LabVIEW can expose properties and methods of the LabVIEW application itself and of specific VIs to other ActiveX-enabled applications (for example, Microsoft Excel, Visual Basic, etc.). It does this through the VI Server interface. If you recall the VI Server discussion from Chapter 15, "Advanced LabVIEW Features," LabVIEW's VI Server capabilities are accessible by TCP/IP (other LabVIEW apps only), block diagram functions, and ActiveX.

To enable the ActiveX access to the VI Server in LabVIEW, you must check the appropriate box in Tools>>Options>>VI Server: Configuration, as shown in Figure 16.40.

Figure 16.40. VI Server configuration settings of the LabVIEW Options dialog

By enabling the ActiveX server, you can write external applications in other programming environments, such as Visual Basic or C++, which can interface to LabVIEW. For example, you could write a Visual Basic application that called a VI, showed its front panel, centered it on the screen, ran the VI, and closed itdoing all this programmatically through the ActiveX/VI Server interface. For more information on this capability, consult the LabVIEW manuals.

AppleEvents

On Mac OS X, you can use some LabVIEW VIs, found on the Data Communication>>Protocols>>AppleEvent palette, that provide interapplication communication through AppleEvents (see Figure 16.41).

Figure 16.41. AppleEvent palette

AppleEvents are a Mac OS-specific protocol that applications use to communicate with each other. AppleEvents send messages to other applications or to the operating system itself to open a document, request data, print, and so on. An application can send a message to itself, another application on the same computer, or another application on a remote computer.

You cannot use AppleEvent VIs to communicate with computers that aren't running Mac OS X (such as a PC running Windows). If you need to communicate with other platforms, use a protocol common to all of them, such as TCP/IP.

The actual low-level AppleEvent messages are quite intricateyou can use them with LabVIEW, but you'd better know the Mac OS very well and have a good reference handy. For simpler stuff, though, LabVIEW comes with higher-level VIs for sending some of the popular commands to applications: telling the Finder to open a document, for example. The AppleEvent VIs are located in the AppleEvent subpalette of the Communications palette.

You can find a neat example of how LabVIEW can communicate with Microsoft Excel in the full version of LabVIEW under examples:comm:AE examples.llb.

Pipes

Pipes are a very cool tool, commonly used by computer hackers to transmit data between applications (by "hackers," we mean the good kind . . . like the IT guy in your company who wears a long beard, types 60 words per minute, has a stuffed penguin toy named "Tux" on his desk, and is always talking about how Windows isn't a real operating system). A pipe is basically just a First In First Out (FIFO) queue that acts as a conduit for data in inter-process communication (IPC). There are two types of pipes: named pipes and command pipes.

A named pipe is a special type of file. On Linux and Mac OS X, this can be created using the mknod and/or mkfifo commands (refer to the documentation for your OS shell). On Windows, named pipes are a little differentthey are not real files but exist beneath \\.pipe\, which is a purely virtual directory that Windows uses for named pipesand must be created using the Windows API.

A command pipe is commonly created when you want to execute an application from a command-line and pipe the output to another command-line. In the case of LabVIEW, we can use command pipes when we invoke a command-line application. We can pipe data into the application's input and pipe data out of its standard output.

On Linux, the Pipes VIs may be found on the Connectivity>>Libraries & Executables>>Pipes palette (see Figure 16.42). On Mac OS X, they are mysteriously missing from the palettes, but don't worryyou can find them all located in vi.lib\Platform\system.llb.

Figure 16.42. Pipes palette

LabVIEW does not include support for pipes on Windows. You're probably thinking to yourself . . . "Whata LabVIEW feature that is supported on Linux and Mac OS X, but not on Windows?" Don't get too excited too quicklythe hard-working developers at OpenG have created a pipes library for Windows that is a drop-in replacement for the LabVIEW Pipes VIs. See Appendix C for more information on OpenG and how to obtain this library.

Now, let's take a look at the LabVIEW pipe VIs.

Open Pipe (Connectivity>>Libraries & Executables>>Pipes palette) opens a named pipe and returns file descriptor, which you pass to subsequent Pipes VIs (see Figure 16.43). A named pipe is a special file that can be used to communicate between separate system processes. Unlike a normal file, you must open a pipe in read mode, usually from another process or application, before you open the pipe in write mode so data written to the pipe can be passed to the reading process. Otherwise, an I/O error occurs and the open process fails.

Figure 16.43. Open Pipe

Open System Command Pipe (Connectivity>>Libraries & Executables>>Pipes palette) opens a pipe to a system shell command and returns file descriptors that you can pass to subsequent Pipes VIs (see Figure 16.44). This allows you to interactively pass data to a command-line application's standard input and read data back from its standard output.

Figure 16.44. Open System Command Pipe

Read From Pipe (Connectivity>>Libraries & Executables>>Pipes palette) reads a number of bytes from a pipe, returning the results in the data string output (see Figure 16.45). For this VI, you must have opened the pipe as a read pipe. The VI does not wait for data, so if the amount of data is not available, the VI returns any available data.

Figure 16.45. Read From Pipe

Write To Pipe (Connectivity>>Libraries & Executables>>Pipes palette) writes a data string to a pipe (see Figure 16.46). For this VI, you must have opened the pipe as a write pipe.

Figure 16.46. Write To Pipe

Close Pipe (Connectivity>>Libraries & Executables>>Pipes palette) closes a pipe (see Figure 16.47). Other processes reading the pipe will receive EOF (end of file).

Figure 16.47. Close Pipe