Passing class-based objects as parameters between a server and ABL client
Objects can be passed as INPUT, OUTPUT, and INPUT-OUTPUT parameters between a server and an ABL client. Because parameters are passed by value between a server 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 client session will raise a run-time error on the RUN statement. (Any logic associated with class members, like the GET and SET methods of a property, can differ on the client and server sides without raising an error, as long as their signatures 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 side 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 a server 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 server 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.