Passing class-based objects as parameters between an AppServer and an ABL client
Objects can be passed as INPUT, OUTPUT, and INPUT-OUTPUT parameters between an AppServer and an ABL client. Because parameters are passed by value between an AppServer and client, the object on the receiving side is a new instance, and the original may be garbage collected if it is not referenced elsewhere. A class must be defined on both client and server sides for objects of that class to be passed as parameters, and the data members, properties, events, and method signatures must match exactly on both sides. Otherwise, the AVM will raise a runtime error on the client-side RUN statement. (Any logic associated with class members, like the GET and SET methods of a property, can differ on the client and AppServer sides without causing an error, as long as their definitions match.)
An object passed as a parameter is serialized and then reconstructed from the serialized data on the receiving side. All non-static data members, properties, ProDataSets, and temp-tables of an object are serialized. Deserialization of an object on the receiving happens starting with the root class and continuing down through the most-derived class. No instance constructors are called, and GET and SET methods for properties are not invoked during serialization or deserialization. The values of the properties are simply transferred.
The following restrictions apply to objects being passed as parameters (or thrown as errors) between an AppServer and client:
In the case of a user-defined class, the object’s class and all of the classes in its hierarchy must be marked as SERIALIZABLE. For more information on marking a class as SERIALIZABLE, see the CLASS statement entry in OpenEdge Development: ABL Reference.
The content of static data members is not serialized, and the state of queries, buffers, open files, streams, and event subscriptions, for example, are not maintained.
All of the object's data members that are defined as class-based objects must be of a class type that is also marked SERIALIZABLE. (This restriction does not apply to static data members that are defined as objects, because static data members are not serialized.)
Handle-based variables are serialized, but no information for reconstructing handle-based objects on the receiving side is serialized.
MEMPTRs assigned by an ABL application are serialized, but MEMPTRs from an external source (such as a DLL or shared library) are not serialized.
Statically defined temp-tables and ProDataSets in user-defined classes are serialized, except for REFERENCE-ONLY tables.
The REJECTED, ERROR, ERROR-STRING, and DATA-SOURCE-MODIFIED attributes for temp-tables in an object are maintained as part of the deserialization process. Similarly, the REJECTED and ERROR attributes for ProDataSets are maintained during serialization.
Not all built-in classes are serializable. See the CLASS statement entry in OpenEdge Development: ABL Reference for a full list of serializable built-in classes.
.NET and ABL-extended .NET objects cannot be passed as parameters.
Temp-tables and ProDataSets that contain class-based objects can be passed between AppServer and client as long as the objects also satisfy these restrictions.
In the case of a user-defined class, the object’s class and all of the classes in its hierarchy must be marked as SERIALIZABLE. For more information on marking a class as SERIALIZABLE, see the CLASS statement entry in OpenEdge Development: ABL Reference.