Bitter, Rick et al "ActiveX" LabVIEW Advanced Programming Techinques Boca Raton: CRC Press LLC,2001 7 ActiveX As many readers have known and suspected, there is a lot more to ActiveX than a LabVIEW interface. ActiveX is a relatively new technology that wraps around several other technologies, namely OLE and COM. This chapter gives a general outline of ActiveX, COM, and OLE technologies and how they may be applied by the LabVIEW programmer using versions 5.0 and 5.1. This chapter covers only the Windows 95, 98, NT, and 2000 versions of Lab- VIEW; Windows 3.1 does not support COM, ActiveX, or OLE Version 2. The core of ActiveX, COM, is currently being ported to other operating systems. As the COM subsystem is ported to other operating systems, support for ActiveX will follow. The political nature of competing operating systems’ vendors suggest that one shouldn’t hold one’s breath, however. Component Object Model (COM) is a new programming paradigm for software development. Microsoft is providing a path for developers to practice component- based development. The mechanical and electrical engineering communities have long practiced this. When designing a circuit board, resistors (components) are chosen from a catalog and purchased for use on the circuit board. Software devel- opers have never truly had a component-based development environment. Libraries, both static and dynamically linked, have been available for quite some time, but were never well suited for component development and sale. Many com- panies are unwilling to distribute information about code modules such as header files or the source code itself. Dynamically-linked libraries have proven difficult to work with since no mechanisms for version control are provided. Libraries may be upgraded and older applications may not be able to communicate with the upgraded versions. The ActiveX core, COM, is a standard that attempts to address all the major issues that have prevented software component development and sale. The result is expected to be a large pool of components that programmers may assemble to create new applications. Ultimately, this chapter will provide the background needed for Win32 LabVIEW developers to take advantage of the new component architecture. LabVIEW itself may be called as an ActiveX component, and may call other components. The VI Server has two implementations, one as an ActiveX control for Win32 usage, and a TCP-based server that may be used by LabVIEW applications on non-Windows platforms for remote control. The VI Server feature will also be covered in this chapter. ©2001 CRC Press LLC 7.1 INTRODUCTION TO OLE, COM, AND ACTIVEX In the beginning, there was Windows 3.1 and the clipboard. The clipboard was the only means for Windows applications to exchange data. Windows 3.1 then supported DDE and OLE Version 1. Dynamic Data Exchange, DDE, was a means for applications to communicate and control each other. OLE represented Object Linking and Embedding, a mechanism for applications to present data belonging to other applications to users. OLE also provided support for drag-and-drop files. These were fairly significant advancements. Visual Basic also introduced the .vbx file, Visual Basic eXtension. A Visual Basic Extension was generally a control, similar to the controls we use in LabVIEW. These controls helped expand the range of applications that could be written in Visual Basic. The functionality of the VBXs proved to be wildly popular. VBXs worked well in the 16-bit Windows 3.1 world, but were only usable by Visual Basic. When 32-bit Windows 95 and NT 4.0 came out, it turned out to be difficult to port the 16-bit VBX controls. The decision to redesign the VBX control was made, and it was determined that OLE was the mechanism that would support it. Beneath OLE was COM, the component object model. COM, OLE, and ActiveX have become somewhat stable these days. Program- ming in Windows with new technologies can be troublesome, as Microsoft tends to evolve technologies after they have been released. ActiveX developers know and understand that the COM standard is well defined and has not changed much, but the implementation of this technology has changed quite a bit in the last few years. Support for ActiveX and COM development now exists in the Microsoft Foundation Classes (MFC) and the ActiveX Template Library (ATL). The ATL has evolved in the last couple of years, and developers also understand that code development between Visual C++ 5.0 and 6.0 has changed. As ActiveX users, we do not need to be concerned with the implementation issues; all we care about is that properties and methods can be invoked regardless of what the developers need to do to make it work. If you choose to develop your own ActiveX controls, you will need to do some research on which development tools and libraries to use, such as Visual Basic or C++. Additionally, be aware that COM+ has been released with Windows 2000. There are potential issues for developers with this new release of COM. 7.1.1 DEFINITION OF RELATED TERMS This section will introduce a few definitions that are commonly used when working with COM technologies. Several terms are introduced in Chapter 9, Multithreading, and will be used again in Chapter 10, Object-Oriented Programming. 7.1.1.1 Properties and methods All ActiveX controls have some combination of Properties and Methods that are available for other applications to control. Properties are variables that are exposed to outside applications. Properties can be configured to be readable only, writable only, and read-write. The act of reading a property is referred to as a GET; writing ©2001 CRC Press LLC a variable is a SET. The ActiveX control maintains a list of properties that may be accessed by external applications. Methods are functions that are executable to external applications. Methods may require arguments and have return values. Not all functions internal to an ActiveX control may be called by external code. The Active X control maintains a list of functions it exports. Calling a method is referred to as “invoking” the method. 7.1.1.2 Interfaces An interface is a group of properties and methods. ActiveX controls may support (and always do) more than one interface. One such interface that all COM objects support is IUnknown. This interface is used to identify the location of other inter- faces, properties, and methods. The rules of COM require that once an interface is published, it cannot be changed. If programmers want to add functionality to a COM object, they must add a new interface and make changes there. All COM objects have one interface that is identified as the default interface. The interface LabVIEW uses is selected when the user inserts the control into LabVIEW. Some controls have a single interface; other controls, such as for Microsoft Access, support hundreds of functions spread across dozens of possible interfaces. 7.1.1.3 Clients and Servers COM and its derivative technologies, OLE and ActiveX, use a client and server connection to communicate with LabVIEW. When LabVIEW is accessing an ActiveX control, LabVIEW is the client application and the ActiveX control is the server. As a client, LabVIEW becomes capable of executing methods and accessing properties of the ActiveX controls that LabVIEW “owns.” When LabVIEW is being controlled via an external application, LabVIEW becomes the server. Other applications, which may or may not be running on the same machine, use LabVIEW’s services. Other clients can include Visual Basic applications, applications written in C++, and even Microsoft Office documents with scripting support that can control LabVIEW. 7.1.1.4 In-Process and Out-of-Process An In-Process ActiveX control is equivalent to a DLL that is loaded into the same memory space as LabVIEW. Chapter 9, Multithreading, discusses protected memory. When an ActiveX control is loaded into the same memory space as LabVIEW, it falls under the complete control of LabVIEW. When LabVIEW exits, the ActiveX control must also exit, and the memory space it resides in will be reclaimed by the system. Out-of-Process controls are independent applications that are controlled through the COM subsystem. A special DLL called a “proxy” is loaded into LabVIEW’s memory space. Calls to the external object are made through this proxy. The purpose of the proxy is to make it transparent to programmers whether the control that is being programmed is in-process or out-of-process. Passing data between processes is a much more difficult task than many people appreciate, especially when data ©2001 CRC Press LLC with unknown size (strings) are being transported across process boundaries. The proxy uses a mechanism called “marshalling” to pass data between processes. For more information on processes and protected memory space, refer to Chapter 9. 7.2 COM The core of the Component Object Model is a binary interface specification. This specification is language- and operating system-independent. Attempts are currently underway to port the COM specification to other operating systems such as UNIX. COM is the foundation of a new programming paradigm in the Win32 environment. ActiveX and OLE2 are currently based on the COM specification. Neither technol- ogy replaces or supercedes COM. In fact, both OLE and ActiveX are supersets of COM. Each technology addresses specific programming issues, which will be dis- cussed shortly. Because COM is intended to be platform- and machine-independent, data types are different in COM than standard types in the C/C++ language. Standard C/C++ data types are anything but standard. Different machines and operating systems define the standard types differently. A long integer has a different interpretation on a 32-bit microprocessor than on a 64-bit microprocessor. Types such as char are not defined in COM interfaces; a short, unsigned data type is defined instead. COM defines its types strictly and independently from hardware. COM does define a couple of data types in addition to primitive types used by nearly every language. Date and currency definitions are provided as part of the interface. Suprisingly, color information is also defined in COM. OLE and ActiveX controls have the ability to have their background colors set to that of their container. The information identifying background colors is defined in the COM specification. COM also uses a special complex data type, the variant. 7.2.1 THE VARIANT Programmers with experience in Visual Basic, Visual Basic for Applications, and Visual Basic Script have heard of a data type called the variant. Variants do not have a defined type; these variables are meant to support every data type. In high-level languages such as VBScript, the variant allows for simple, fast, and sloppy program- ming. Programmers are never required to identify a variable type. The variant will track the type of data stored within it. If a variant is reassigned a value of a different type, it will internally polymorph to the new type. ActiveX, COM, and OLE controls allow the usage of variants, and therefore they must be supported in LabVIEW. We’ve encountered a number of issues with the variant type in LabVIEW, and this section will help explain what this data type is and how it works “under the hood.” From a low-level language such as C++, variant programming can be difficult. The variant type has a number of binary flags that are used to indicate what type of data it contains. For example, variants can contain integers or arrays of integers. A C++ programmer needs to check binary flags to determine which primitive type (integers) and if any flags such as array are set. LabVIEW programmers go through similar problems; we need to know what type of data the variant is supposed to ©2001 CRC Press LLC contain and convert it to G data. The “To G Data” function is explained later in this chapter. LabVIEW programmers do not need to check for unions and bit-flags to work with Variants. We do need to know what type of data an ActiveX control is going to pass back, however. If you choose the wrong type, LabVIEW will convert it and give you something back you probably do not want. Variants do not support every type of data. For example, it is not possible to represent defined pointers, C++ class objects, or structures in a variant. Advanced programmers will understand that void pointers can be contained in variants. Void pointers are pointers to memory addresses that do not contain information as to what is being pointed at. The programmer must know what a void pointer references before they can use it. The reason pointer operations are not supported in COM is because not every language supports the use of pointers. For example, LabVIEW programmers never need to concern themselves with memory addresses. To support COM’s design to be platform- and language-independent, variants support primitive data types and a number of types defined in the COM standard. For example, dates and currencies are defined data types that COM supports. Strong words of warning need to be communicated if you are dealing with variant strings. The problem that needs to be understood by the LabVIEW program- mer relates to Unicode versus ANSI strings. The standard string type is ANSI, a string being represented by an array of 8-bit unsigned integers. A new standard, Unicode, was introduced because eight-bit strings are not very useful for languages other than English. Unicode strings consist of 16-bit unsigned integers. When con- verting strings to LabVIEW strings, you may have the unpleasant surprise of finding that the variant flattened out into an empty string. This is because LabVIEW was trying to convert a 16-bit array into an 8-bit array. This will not work in LabVIEW, and it took us several days of examining code to identify the nature of the problem. Windows 95 and 98 are built on handling ANSI strings (eight bits), with one exception. Windows NT is built entirely on Unicode strings (16-bit). Windows NT will do Unicode-to-ANSI string conversions internally when necessary. The string translation will be transparent to the programmer and user. The one exception to ANSI strings in Windows 95 and 98 is the OLE2 library. COM, ActiveX, and OLE use this library, which is built entirely on Unicode string handling. When using variant strings in LabVIEW, they MUST be converted to arrays of eight-bit integers and then converted to strings. If this is not done, you will always receive empty strings from a variant conversion. LabVIEW will otherwise try to convert the 16-bit string as an 8-bit string. When this is attempted, the string will always return empty. The variant’s first eight-bit value will be hex 0; the zero will be interpreted as a NULL string, a string with zero length. Converting the variant to an 8-bit array will force the conversion of the 16-bit numbers to 8-bit numbers, and the string will be recovered. Communications applications rarely use 16-bit characters. UDP, TCP, Serial, and GPIB data is always an eight-bit character base. Microsoft built Windows NT and the OLE2 library on Unicode strings to address another issue that is important in the world today. ASCII strings work well when your primary language is English. If your primary language is not English, but is based on the same alphabet as English, such as Spanish, then ASCII is not that bad. If you happen to be from the Far East, ©2001 CRC Press LLC then ASCII strings can be quite difficult. You are required to either wait for custom versions of Windows for your native language to become available or use English versions. Unicode addresses this, by providing a base character that can cover over 65,000 possible letters. This is not a perfect solution, but it does address computer issues that impact a majority of the world’s population. 7.2.2 PROBLEMS THAT COM ADDRESSES COM addresses a number of component development issues. One such issue is interface requirements. The COM specification demands that once an interface has been shipped, the interface is “cast in stone.” If additional functionality is desired, it must be added in an additional interface. COM does allow an object to present multiple interfaces. This has been a characteristic problem with DLL development. When a DLL interface is changed, many older applications will not be able to cope with the new interface and will crash. All COM objects provide IUnknown, a specific interface. This allows a COM-based application to have a guaranteed entrance point to the object to identify what functionality the object provides. LabVIEW program- mers who develop or use custom DLLs can implement the DLL functionality as ActiveX/COM objects and use the code in multiple applications. Environments such as Visual Basic have shown that ActiveX component programming is fairly easy, easier than using DLLs. The interface defined by COM and expanded on by ActiveX is intended to simplify programming. Since the COM specification defines a common interface, why not expand the model to distributed computing? Microsoft did, and the result is DCOM—Distrib- uted COM. This is a concept that DLLs alone could never have provided. Without the common DCOM specification, developers would have to develop custom inter- faces for distributed application development. The use of a distributed object model offers many potential benefits to LabVIEW developers who program in an environ- ment utilizing multiple computers. 7.2.3 IN-PROCESS AND OUT-OF-PROCESS COM OBJECTS COM objects may be represented in one of two manners: DLLs and executable applications. A DLL is linked into an application when it is started up. A COM object implemented as a DLL is referred to as an in-process COM object. In-process COM objects are loaded into the same memory space as the client application. A COM object implemented as an executable application is an out-of-process COM object. In order for the client application to access the COM object’s methods, an interprocess communication must occur. In general, communication with in-process COM objects is faster than out-of-process COM objects. When data crosses a process boundary, the operating system must become involved. As processes are switched into and out of physical memory, different threads of execution take over the CPU. This procedure generates additional overhead. This does not happen with in-process COM objects. The fact that out-of-process communication occurs should not dis- suade a LabVIEW programmer from using COM servers. This is something that developers will need to be aware of when developing time-critical applications. ©2001 CRC Press LLC One advantage out-of-process servers have is stability. When an application is started, it is given its own address space and threads of execution. In the event that one process crashes, the other processes will continue to execute. These other processes may experience problems because a peer crashed, but good exception handling will keep other processes alive to accomplish their tasks. It is possible to crash peer processes, but defensive programming can always mitigate that risk. Out- of-process servers can also be run on different machines using DCOM, which allows for the process to continue executing even if one machine crashes. There are appli- cations in monitoring and production software for distributed computing. 7.2.4 COM OBJECT IDENTIFICATION COM Objects have two forms of names: a text-based name that programmers and users can identify, and a Globally Unique ID (GUID). The GUID is a 128-bit number that is unique. The compiler assigns the GUID when the control is initially generated. Among other pieces of information that are used are the time and machine address of the computer that generated the control. This is not a completely foolproof scheme, but to a very high probability, the GUID number will be unique in the world. The GUID is stored in the user computer’s registry and is used by the COM subsystem to identify the object and its location on a hard drive or on the Internet. Programmers rarely, if ever, use the GUID, and this will not be discussed further. COM Objects have an object-type library file associated with them. This library file identifies methods, properties, and interfaces the object supports. COM objects must also be registered with the system. The Win32’s registry will contain an entry identifying the path to the object and type library. When an application requests a connection to the object, it contacts the operating system, and the operating system provides the linkage. The application will read the type library, which identifies the methods that the object supports. The type library uses a specified language called IDL, Interface Description Language. IDL descriptions are compiled to become the type library. The use of COM objects and the type library is more stable than the standard use of DLLs. When a bad link is made to a DLL, the application will probably crash. If your application contacts the operating system to link to a COM object, and something is not working, the operating system will respond with an error message. The COM object itself may be in a different process or machine, and can also provide extra levels of isolation. When a programmer identifies an ActiveX class while programming, the appli- cation shows a list of interfaces the control supports. This information is read from the type library. In reality, the operation is much more complicated and beyond the scope of this discussion. Readers familiar with C and C++ recall the use of pointers. COM uses a virtual table that is exposed by the IUnknown interface. This table is not built of the functions the COM object supports, but is built of pointers to the functions. This double indirection actually gives COM an advantage. One of the rules of the COM specification requires that interfaces never be changed once they are published. Each and every ActiveX object you use in your LabVIEW applications will not need to be changed, ever. Regardless of what developers do to the objects you use, the ©2001 CRC Press LLC interfaces will not change. COM does give the developers flexibility as to what happens internally to the COM object. The virtual table can point to different functions. The table itself will change structure. Again, standard DLLs do not have this requirement; you may have to make changes to each application that uses a DLL that has been changed. 7.2.5 HOW COM OBJECTS ARE CALLED AND USED All COM objects present an interface called IUnknown. This interface is used to describe the COM object itself, and performs a multitude of functions. Most of the IUnknown interface is well beyond the scope of this book. In fact, the average ActiveX programmer does not write their own IUnknown interface; they use code generated by Microsoft tools. For example, when writing a control in Visual Basic, the programmer never sees code related to the IUnknown interface. COM also has several other interfaces, but as LabVIEW programmers we do not need to be concerned with these other interfaces’ existence. COM objects export their functions in a type library. The type library defines what properties and methods are available. Each property defines if it can be read or written, and functions indicate their argument lists and return types. The type library is compiled and cannot be read by a programmer. Type libraries are written in either Object Description Language (ODL) or Interface Description Language (IDL). IDL is the more recent language and is generated by compilers for COM objects. The IDL files are compiled into the type libraries. This section will discuss two methods that applications use when linking to ActiveX controls: early and late binding. Binding is a process by which sections of code integrate themselves. There is a lot of behind-the-scenes pointer handling, and the process can get quite messy. Early binding means that the application and ActiveX control are linked together when the application is compiled. This is a fairly fast startup, functionally the ActiveX control (an .ocx file) is a DLL that is being merged at startup. The compiler uses the type library to build the application. Late binding is the process by which the ActiveX control is loaded in while the application is executing. As mentioned in the last paragraph, an OCX file is a DLL with some specific interface functions. In general, this is a slower process than early binding. Late binding is an important concept for LabVIEW programmers, because this is how LabVIEW binds to ActiveX controls. When an application performs late binding, the operating system is asked to query the registry about the component. Late binding uses a different interface, and a Virtual Table is set up. A “vtable” is simply a list of pointers that are used to identify functions contained inside the control. Conceptually, this is an extremely messy operation, and it is generally covered up by the programming language’s code. For example, LabVIEW and Visual Basic programmers never need to know or worry about the pointer tables being set up. Suprisingly, C++ programmers have little to worry about also. The MFC classes ©2001 CRC Press LLC provide a lot of this functionality. The C++ programmer has the freedom to replace the supplied interface code, however. Late binding is not significantly slower than early binding. What can hurt the programmer is the registry query and loading the control into memory. Disk access can be slow when compared to the execution speed of the application. The actual overhead of a late-bound control is going through the virtual table to identify the starting memory address of a function. With modern CPUs running at speeds over 300 MHz, a few extra clock cycles is negligible in a vast majority of applications. Real-time programmers are the only ones who should be considering this. This is important to the LabVIEW programmer because all ActiveX controls you use will be bound late. When writing applications using ActiveX, always start up the controls at the start of your VI. This will eliminate the chance that an ActiveX control will slow down the application at sensitive times. 7.3 OLE We will demonstrate in Section 7.4 that OLE interfaces are in fact, ActiveX objects. The reverse is not always true; some ActiveX objects are not OLE interfaces. OLE is an interfacing technology used for automation, the control of one application by another. Many programmers subscribe to the myth that ActiveX has replaced OLE—this is not true. OLE is a subset or specialization of ActiveX components. In general, ActiveX will be more widely used. LabVIEW applications that are control- ling applications like Microsoft Word and Excel are using OLE, not ActiveX. A document is loosely defined as a collection of data. One or more applications understand how to manipulate the set of data contained in a document. For example, Microsoft Word understands how to manipulate data contained in *.doc files and Microsoft Excel understands .xls files. There is no legitimate reason for the Word development team to design in Excel functionality so that Word users can manipulate graphs in their word documents. If they did, the executable file for Word would be significantly larger than it currently is. OLE automation is used to access documents that can be interpreted by other applications. 7.3.1 ORIGINS AND APPLICATIONS OLE once meant “Object Linking and Embedding,” but this is no longer the case. OLE was initially designed to allow embedded documents, and still serves this purpose. To an extent, OLE was designed to replace Dynamic Data Exchange. LabVIEW 5.0 still supports DDE, but it no longer has an OLE palette. The OLE palette is no longer necessary because OLE functions operate exactly like ActiveX functions. While DDE is still available to the LabVIEW programmer, its use should not be designed into new applications. DDE is a legacy communications protocol, which means it could disappear from the world of Windows with little warning. ©2001 CRC Press LLC