There are three ways to access PowerBuilder user objects. You can access:
A PowerBuilder class user object that you have defined and registered
PowerBuilder itself as the server, after which you can create any object whose definition is in the libraries you have specified
A named server that allows you to use a name appropriate for your business while giving you access to the PowerBuilder server
You can define a class user object and register it in the registry. When you use your client’s functions for accessing an external object, you have access to the user object’s properties and functions. (Automation accesses the object’s instance variables as properties.)
The advantages of a registered user object as an automation server include:
Browsable information about the object in the registry, making it easy for others to program the object
Simpler client code for accessing the object
Restriction of client access to classes you publish in the registry, return from function calls, or declare as instance variables of the user object
Figure 20-2: Interaction of class user object as server with client
For you to access an independent user object, it must be installed as an independent entity in the registry. You connect to it by means of an OLEObject variable and use automation to access it. The object invokes a PowerBuilder runtime session to support it.
When you access the object in your runtime session, you create a single instance of the object, and PowerBuilder invokes a runtime session to support it. For each registered object you create, you incur the overhead of additional runtime sessions.
The steps you take to register and use a user object are described in “Using a user object as an automation server”.
When you install PowerBuilder, an entry is added to the registry for PowerBuilder.Application, a general-purpose PowerBuilder automation server. You can create instances of any number of class user objects and access their properties and methods. (Automation accesses the object’s instance variables as properties.)
The advantages of using PowerBuilder.Application include:
Access to more than one object without invoking the overhead of more than one PowerBuilder runtime environment.
Direct access to all system and private classes available in the library list. These classes can be instantiated using the CreateObject function of PowerBuilder.Application.
When you connect to PowerBuilder.Application, you specify the libraries that you will access. You can instantiate any number of user objects whose definitions reside in those libraries, as well as system classes.
Each object you create in the client exists as an independent OLEObject in the client, and you can address each one using automation. If the client passes a server object reference back to another server object in the same runtime session, PowerBuilder recognizes the PowerBuilder datatype of the object. This allows the two objects to interact in the server session, rather than being limited to automation commands from the client.
Figure 20-3: Objects interacting in a server session
The steps you take to set up and use PowerBuilder.Application are described in “Using PowerBuilder as an automation server”.
For business reasons, you might want to avoid references to PowerBuilder.Application, but still have access to the additional functionality it provides—for example, the efficiency of instantiating more than one object in a server session.
You can create an entry in the registry that serves as a second pointer to PowerBuilder.Application, allowing you to give the server a name appropriate for your business.
The steps involved in setting up a named server are described in “Creating and using a named server”.
