Parameter passing syntax

INPUT parameters — The data type of the passed parameter can be narrower than the defined parameter.

OUTPUT parameters — The data type of the passed parameter can be wider than the defined parameter.

INPUT-OUTPUT parameters — Widening is not supported. Because values are passed in both directions, the data type of the passed parameter must exactly match the data type of the defined parameter.

When the .NET method or constructor is overloaded by multiple implicit .NET data type mappings for the passed ABL primitive type and the method you want is not identified by the default match for the passed ABL data type. Thus, by explicitly specifying an AS data type, you can disambiguate the implicit .NET overloadings for the method or constructor.

The parameter is defined as a System.Object, and you want the .NET value of the passed ABL primitive type to be stored as a .NET mapped data type that is not the default match. For example, you might want the System.Object parameter to store an ABL INTEGER value as a System.Int16 instead of as a System.Int32 (the default match).

Binding a reference-only static object defined in one routine to an object instance defined in another routine

Binding an unknown TABLE-HANDLE or DATASET-HANDLE parameter defined in one routine to an object instance defined in another routine

The requirements for calling and passing parameters to built-in handle methods and COM object methods have unique features not shared in calls to procedures, user-defined functions, and methods of a class or class constructors. For information on calling and passing parameters to built-in handle methods and COM object methods, see the information on calling these types of methods in the Handle Attributes and Methods Reference.

You do not invoke a class constructor directly. To invoke a constructor, you pass constructor parameters in statements that participate in instantiating the class, such as the NEW function (classes), SUPER statement, or THIS-OBJECT statement. The constructor that is invoked matches the particular signature of the parameters that you pass.

When you call the Publish( ) event method to publish a class event, or when you execute the PUBLISH statement to publish a named event, any parameters are passed to every event handler that is subscribed to the event. However, any parameter values returned from the Publish( ) method or PUBLISH statement reflect the settings of the last event handler to execute. Therefore, when you publish a class or named event, the value returned for an OUTPUT or INPUT-OUTPUT parameter, or for a member of any object (class or handle-based) referenced in an INPUT parameter, depends on the execution order of the event handlers subscribed to the event, which is not guaranteed. In addition, for INPUT-OUTPUT parameters or for members of objects referenced by INPUT parameters, the values returned from each event handler are used as input to the next event handler that executes.

You cannot pass a CLOB or BLOB directly as a corresponding LONGCHAR/CHARACTER or MEMPTR parameter. You must first assign the CLOB to a LONGCHAR/CHARACTER or assign the BLOB to a MEMPTR and pass the result. For information on assigning large object data, see the Assignment (=) statement reference entry.

When you instantiate a class dynamically, using the DYNAMIC-NEW statement, ABL distinguishes overloaded constructors only by the number of parameters.

When you call overloaded methods or constructors that differ by a parameter that supports widening, ABL looks for an exact data type match at compile time. If an exact match is not found, the compiler will look for the closest widened match.

When you pass an ABL array parameter, ABL initiates an array assignment that makes a deep copy of the array source to the array target, depending on the parameter mode. For more information on array assignments, see the Assignment (=) statement reference entry.

For INPUT parameters of .NET methods or constructors defined with certain .NET data types, ABL supports widening relationships that allow you to pass ABL arguments with different ABL data types than those supported for implicit mapping to .NET data types (see Table 24 in the Data types reference entry).

For OUTPUT parameters of .NET methods or constructors defined with certain .NET data types, ABL supports widening relationships that allow you to pass ABL arguments with different data types than those supported for implicit mapping to .NET data types (see Table 24 in the Data types reference entry).

If you are passing an ABL object reference to an OUTPUT or INPUT-OUTPUT parameter defined as an unmapped .NET type, ABL treats any type returned by .NET as a class.

If you assign a .NET value type object returned as an OUTPUT parameter from a .NET method to an ABL object reference variable, the returned object referenced in ABL is a separate copy from the original value type instance maintained by .NET. However within the ABL session, the object reference to the ABL copy, when passed as a parameter, is passed by reference like any object reference to an ABL class instance.

ABL allows you to pass ABL arrays (defined with EXTENT) and .NET array objects to each other. Passing an array parameter of any type constitutes an array assignment whose direction moves from the source to the target array according to the parameter mode. How this array assignment works for ABL and .NET array parameters depends upon the types of the source and target arrays. For more information, see the Data types reference entry.

For temp-table parameters or temp-tables passed as part of a ProDataSet parameter, the AVM does not check for matching temp-table field data types if the SCHEMA-MARSHAL attribute for the temp-table is set to "NONE".

You cannot pass a REFERENCE-ONLY buffer or a BEFORE-TABLE buffer as a BUFFER parameter. It also does not matter if a REFERENCE-ONLY buffer has been bound. Passing these kinds of buffers as a BUFFER parameter (as opposed to passing them as an INPUT or OUTPUT parameter) raises a compiler error. Instead of passing the buffer as a parameter, you can pass the buffer's temp-table as a BY-REFERENCE TABLE or TABLE-HANDLE parameter.

You cannot pass a BUFFER parameter to a remote procedure. Otherwise, the AVM raises a run-time error.

Class-based objects can be passed between an OpenEdge application server and an ABL client. The objects are serialized on the sending side, and a copy is deserialized on the receiving side. The following restrictions apply to objects being passed as parameters between an OpenEdge application server and client:

The object's class and all of the classes in its hierarchy must be marked as SERIALIZABLE. See the CLASS statement entry for more information.

All of the object's data members that are themselves defined as class-based objects must be of class types that are also marked SERIALIZABLE.

The class must be defined on both the client and server sides, and the data members, properties, methods signatures, and events on both sides must match exactly.

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.

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.

CHARACTER values are serialized using the codepage defined in -cpinternal, and the values are converted using the codepage defined for -cpinternal in the session that does the deserialization. LONGCHAR values are also converted using -cpinternal unless their codepage is fixed with the FIX-CODEPAGE statement, in which case the fixed codepage is used. An error is raised if the conversion fails.

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.

The only built-in object types that can be passed as parameters are Progress.Json.ObjectModel.JsonObject, Progress.Json.ObjectModel.JsonArray, and Progress.Json.ObjectModel.ObjectModelParser, and the built-in error objects.

.NET and ABL-extended .NET objects cannot be passed as parameters.

You can pass a temp-table or ProDataSet containing an object reference field as a parameter between an OpenEdge application server and an ABL client, as long as the objects themselves satisfy the restrictions placed on all class-based objects being passed between an OpenEdge application server and an ABL client.

If you call a remote procedure asynchronously and pass a parameter as OUTPUT TABLE-HANDLE temp-table-handle APPEND, the event procedure must specify a corresponding DEFINE INPUT PARAMETER TABLE-HANDLE FOR temp-table-handle APPEND statement, and temp-table-handle must be global to both the calling procedure and the event procedure.

If you pass a TABLE-HANDLE parameter to a method of a class or a class constructor, where the method or constructor is overloaded with corresponding TABLE-HANDLE and TABLE parameter definitions, the AVM executes the method or constructor that best matches the TABLE-HANDLE parameter. If the schema of the TABLE-HANDLE parameter matches the schema of the TABLE parameter definition, the AVM executes the method or constructor with the TABLE parameter definition. Otherwise, the AVM executes the method or constructor with the TABLE-HANDLE parameter definition.

If you pass a DATASET-HANDLE parameter to a method of a class or a class constructor, where the method or constructor is overloaded with corresponding DATASET-HANDLE and DATASET parameter definitions, the AVM executes the method or constructor that best matches the DATASET-HANDLE parameter. If the schema of the DATASET-HANDLE parameter matches the schema of the DATASET parameter definition, the AVM executes the method or constructor with the DATASET parameter definition. Otherwise, the AVM executes the method or constructor with the DATASET-HANDLE parameter definition.

If you pass a class instance to overloaded methods or constructors whose corresponding class parameters differ only within the same class hierarchy, ABL looks from the bottom of the class hierarchy, starting with the most derived class, and chooses any method or constructor whose corresponding parameters are defined for the same class as the passed parameter. Otherwise, the AVM chooses any method or constructor whose corresponding parameters are defined for the most derived class in the same class hierarchy, which is also a super class of the passed parameter.

If you pass a class instance to overloaded methods or constructors whose corresponding class parameters differ by one or more interfaces that the class implements, only a method or constructor whose corresponding class parameter exactly matches the class of the passed parameter is acceptable to the compiler. Otherwise, the AVM generates a compile-time error for ambiguity, as one implemented interface is no better match than another.

If you pass the Unknown value (?) to a parameter of an overloaded method or constructor, the AVM only selects the correct method or constructor to execute when passing the Unknown value (?) causes no ambiguity among them. Otherwise, the AVM generates a compile-time error for ambiguity.

If you pass an ABL expression to an overloaded method or constructor whose data type cannot be known at compile-time (for example, the BUFFER-VALUE attribute), the AVM can only call the correct method or constructor at run time, and only when the overloaded method or constructor differs by more than the parameter with an unknown data type. Otherwise, the AVM raises a run-time error for ambiguity.

You can avoid compile-time ambiguity errors when passing the Unknown value (?) or an expression of an unknown data type in one of two ways:

Convert the Unknown value (?) or expression to a specific data type using the appropriate ABL data type conversion function to pass the value.

Assign the Unknown value (?) or expression to a variable of a specific data type to pass the value.

If you pass a method of a class as a parameter to another method, constructor, procedure, or user-defined function that you invoke, and the method parameter executes the RETURN statement with the ERROR option, the method, constructor, procedure, or user-defined function that you invoke does not run. The AVM then raises ERROR on the invoked method, constructor, or procedure. The AVM does not raise ERROR on an invoked user-defined function.

A parameter list that contains the word "DATASET" or "BUFFER", where the parameter is not a DATASET or BUFFER parameter, but an expression involving those keywords, may be ambiguous, causing a compiler error. If this happens, enclosing the expression in parentheses to identify the parameter as an expression will usually fix the ambiguity.