Earlier releases of PowerBuilder provided two ways to generate COM objects: COM servers and automation servers. Both were accessible from wizards and from the Project painter. PowerBuilder COM servers offer many more features than automation servers.
Automation servers no longer available
PowerBuilder no longer supports generating COM object in automation servers.
This section is maintained for informational purposes only.
PowerBuilder COM servers PowerBuilder COM servers can contain more than one custom class user object. After you code the user objects, you use the Project painter to generate a single self-registering DLL for all the objects. You can also deploy the server directly to COM+ if it is running on the build computer, or create a COM+ package. PowerBuilder COM objects in a COM server can share runtime sessions, and references can be passed between objects created from the same COM client.
The COM server also contains an embedded PowerBuilder dynamic library (PBD) file that contains compiled versions of all the custom class user objects you selected and any dependent objects, as well as registry and type library information.
You deploy the PowerBuilder COM server with the PowerBuilder virtual machine, along with any other PowerBuilder runtime files the server requires.
Automation servers Automation servers built from a custom class user object (in earlier versions of PowerBuilder) contained only one object. After you coded the user object, you had to build a runtime library from the PBL that contained it, and use the Project painter to create a registry file and optional type library file. After deploying the automation server, you could customize the registry file for the user’s computer and run the file to register the automation server.
Automation servers use a dispatch interface (also called dispinterface) that allows users to invoke methods on the server using the Invoke method of a standard COM interface called IDispatch.
COM servers can use custom or dual interfaces, which provide better performance than dispatch-based interfaces. A custom interface provides access to methods on the server through a virtual table (also called VTBL or vtable) that contains pointers to methods in the server’s interface. A dual interface enables the client to invoke methods using IDispatch::Invoke or a virtual table.
For more information, see “Choosing a custom or dual interface”.
Table 26-1 summarizes the differences between PowerBuilder automation servers and PowerBuilder COM servers using dual or custom interfaces:
Feature |
Automation server* (dispatch interface) |
COM server (dual interface) |
COM server (custom interface) |
|---|---|---|---|
In-process server support |
Yes# |
Yes |
Yes |
Generated IDL files |
No |
Yes |
Yes |
C++ client support |
No |
Yes |
Yes |
Java client support |
Yes |
Yes |
No |
PowerBuilder client support |
Yes |
Yes |
No |
Visual Basic 4 client support |
Yes |
Yes |
No |
Visual Basic 5 custom interface support |
No |
No |
Yes |
Support for PowerBuilder structures as instance variables and method argument types |
No |
No |
No |
Support for all C language datatypes |
No |
No |
No |
Support for an embedded type library |
No |
Yes |
Yes |
Self-registering servers |
No |
Yes |
Yes |
Support for DCOM $ |
Yes |
Yes |
Yes |
Support for EAServer |
Yes |
Yes |
No |
Support for COM+ |
No |
Yes |
Yes |
Requires separate proxy/stub DLLs |
No |
No |
No |
Requires PowerBuilder runtime DLLs (minimally PBVM115.DLL and its dependencies) |
Yes |
Yes |
Yes |
Requires deployment of application runtime libraries built in Library painter |
Yes |
No |
No |
* Available in earlier releases of PowerBuilder only
# In-process server is the PowerBuilder execution DLL (PBVM115.DLL)
$ Requires use of surrogate host to house the PowerBuilder execution DLL
