Using the runtime automation server

Use PowerBuilder COM servers This chapter focuses on the use of the PowerBuilder runtime automation server. PowerBuilder COM/COM+ server generation is the preferred technique for building COM-compliant servers. The PowerBuilder automation server technology might be discontinued in a future release.

For information about generating PowerBuilder COM objects from custom class user objects, see Chapter 27, “Building a COM or COM+ Component.”

Chapter 19, “Using OLE in an Application,” explains how PowerBuilder provides containers for OLE objects and custom controls and how you can use automation to program those objects. The functionality for those objects is provided by server applications. The programming tells a server application how to manipulate its data.

What the automation server is

The PowerBuilder automation server is an OLE server for programmable objects—rather than insertable, visible objects. It provides access to class user objects (nonvisual user objects) that you have defined in a PowerBuilder library. You can initiate a server session, create one or more objects, and send commands to those objects using automation syntax.

The class user object can create instances of other objects, and the server can pass references to these objects to the client.

Figure 20-1: Server passes class user object references to client

The example shows a client application and a P B D or D L L that contains a library of class user objects. OLE automation commands and returned data flow between the P B D and the client application.

Client applications

Any client application that supports automation and programmable objects can access the PowerBuilder automation server. You can create your client application in any COM-compliant tool such as PowerBuilder, Visual C++, or Visual Basic.

Runtime overhead

Each time you connect to a server, you invoke an instance of the PowerBuilder runtime environment. However, this is not a huge penalty—each runtime shares the definition of the system classes in the client’s runtime session.

User class definitions are not shared. Therefore, if you create the same large objects in each of several runtime sessions, memory usage for an object is multiplied by the number of sessions in which you create it. You could make your application more memory-efficient by reorganizing the application and creating the objects in a single session.