Parameter passing syntax

Specifies one or more parameters to pass during invocation of an ABL procedure, a user-defined function, a method of a class (ABL or .NET), a class constructor (ABL or .NET), or the built-in Publish( ) event method or PUBLISH statement to publish class or named events, respectively.

Syntax

( parameter[ , parameter ]... )

The parameters specified by parameter must match in number and order, according to mode and data type, as required by the given procedure, user-defined function, method, or constructor definition. Use the following syntax to specify each parameter:

[ INPUT | OUTPUT | INPUT-OUTPUT ]
{   parm [ AS data-type]
  | { {   TABLE temp-table-name 
         | TABLE-HANDLE temp-table-handle 
         | DATASET dataset-name 
         | DATASET-HANDLE dataset-handle 
        } [ APPEND ] [ BY-VALUE | BY-REFERENCE | BIND ] 
     }
}

BUFFER buffer

[ INPUT | OUTPUT | INPUT-OUTPUT ]

Specifies the parameter mode. For more information on parameter modes, see the reference entries for the DEFINE PARAMETER statement (for procedures) and the Parameter definition syntax (for user-defined functions, methods, and class events).

Note that for methods and constructors, the parameter mode is optional except for certain overloading conditions. Thus, the default mode depends on the type of invocation, as described in the following table.

Default parameter passing mode

Invocation type	Default mode
Procedure	INPUT
User-defined function	Uses the mode defined for the corresponding parameter in the function prototype. For more information on defining prototypes for user-defined functions, see the FUNCTION statement reference entry.
Method of a class or class constructor	Uses the mode defined for the corresponding parameter in the method or constructor prototype, depending on overloading requirements. For more information on defining prototypes for class-based methods and constructors, see the METHOD statement and CONSTRUCTOR statement reference entries. If the method is overloaded by a given parameter only by mode, you must specify the mode for this parameter in the method call. If you do not do so, ABL raises a compile-time ambiguity error. For example, if a method is overloaded twice by an INTEGER parameter, and the parameter for one method definition has the INPUT mode while the parameter for the other method definition has the OUTPUT mode, you must specify the INPUT keyword if you intend to use the method defined with the INPUT parameter.
Publish( ) event method	Uses the mode defined for the corresponding parameter in the class event definition. For more information on defining class events, see the DEFINE EVENT statement reference entry.

When identifying the parameter mode for a .NET method or constructor, each .NET language uses its own keyword syntax to identify it. The following table shows the C# parameter syntax that corresponds to an ABL parameter specified with a given mode. Note that in C#, the default (no keyword) corresponds to the ABL INPUT mode.

C# syntax matching ABL parameter modes

ABL parameter mode	Corresponding C# syntax
INPUT parm	parm
OUTPUT parm	out parm
INPUT-OUTPUT parm	ref parm

Also note, as with ABL class-based methods, the default parameter passing modes for calling .NET methods and constructors are based on the parameter passing modes defined for the method or constructor prototypes, depending on overloading. Thus, you must specify the parameter passing mode for each affected parameter if the method is overloaded only by a given parameter's mode.

parm

Specifies the argument passed to the parameter. This can be either an ABL data element or Expression, or a .NET data element, depending on the parameter mode. For an INPUT parameter, parm can be an Expression. For an OUTPUT or INPUT-OUTPUT parameter, parm can be any of the elements defined for the left side of an Assignment (=) statement. For an INPUT-OUTPUT parameter, any property argument must be both writable and readable.

Note: Syntactic limitations require that none of the following data items can be an OUTPUT or INPUT-OUTPUT parameter: a writable handle attribute, a writable property (ABL or .NET) on an object reference, or a data member (ABL or .NET) on an object reference. The limitation is that OUTPUT and INPUT-OUTPUT parameters cannot have a colon in their syntax. For example, OUTPUT myObjectRef:WritableProperty is invalid syntax.

For procedures, the data type of parm must be compatible with the data type defined for the parameter. Procedures allow the matching of a wide variety of different data types between the passed parameter and the parameter definition. When it can, the AVM converts the passed value from the source data type to an appropriate value in the destination data type, depending on the direction (parameter mode) of the passed value. For procedures, the AVM checks data type matching and appropriate overflow conditions at run time.

For user-defined functions, methods of a class, class constructors, and the Publish( ) event method, the data types of the passed parameter and the parameter definition are validated by the AVM at compile time and must match exactly, unless they have a widening relationship.

The AVM implicitly converts passed parameter values of certain data types from a narrow data type in the source to a widened data type in the destination, depending on the parameter mode. A widened data type is one that can hold all the values of a narrower data type without loss of data. Widening is supported for three related sets of data types, as shown in the following table, where the arrow ( —>) indicates the direction that a value can be passed for the parameter.

Data type widening support

Narrower —> Wider
CHARACTER	–	LONGCHAR
INTEGER	INT64	DECIMAL
DATE	DATETIME	DATETIME-TZ

Thus, ABL supports the widening of data types in the direction that the parameter is defined, according to its mode:

• 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.

For .NET method parameters, ABL also supports widening relationships between ABL and some .NET data types. For more information, see the notes of this reference entry.

For a parm that involves .NET data types, either as the parameter definition or as the argument, the requirements for parameter passing depend on the parameter and argument data types and the type of routine that defines the parameter. The following table shows the possible combinations.

Note: The following table refers to .NET value types, .NET mapped data types, .NET arrays of mapped types, boxing, and unboxing. Boxing and unboxing refer to a .NET mechanism for converting between .NET value types and .NET object types. ABL supports a similar mechanism for converting between ABL primitive or array types and a .NET System.Object or compatible array object type. For more information on .NET data types, concepts, and compatibility, see the Data types reference entry.

Passing parameters involving .NET types

The following parameter data type . . .	In this routine type . . .	Can take these arguments (parm) . . .
.NET mapped data type1	.NET routine2	The same .NET data type (for example, a .NET property), any corresponding ABL primitive type (as shown in Table 43), and on OUTPUT only, a System.Object4
.NET mapped data type5	ABL method that overrides or implements a .NET method	Any compatible ABL primitive type or any compatible .NET mapped data type (for example, a .NET property) as shown in Table 43,6
.NET array	.NET routine	A compatible .NET or ABL array type7, 8, and on OUTPUT only, a System.Array, System.Object, or Progress.Lang.Object
.NET array	ABL routine9, 10	A compatible .NET array type8,, 11and on OUTPUT only, a System.Array, System.Object, or Progress.Lang.Object,
System.Array	.NET routine	On INPUT, any .NET array object type or compatible ABL array type12, and on OUTPUT only, a System.Array, System.Object, or Progress.Lang.Object
System.Array	ABL routine9, 10	On INPUT, any .NET array object type11, and on OUTPUT only, a System.Array, System.Object, or Progress.Lang.Object
System.Object	.NET routine	On INPUT, any .NET object type, an ABL primitive type, or compatible ABL array type12, and on OUTPUT only, a System.Object or Progress.Lang.Object
System.Object	ABL routine9, 10	On INPUT, any .NET object type11, and on OUTPUT only, a System.Object or Progress.Lang.Object
Any .NET object type (except those in the previous rows)	.NET routine	Any compatible .NET object type, and on OUTPUT only, a System.Object or a Progress.Lang.Object
Any .NET object type (except those in the previous rows)	ABL routine9, 10	Any compatible .NET object type, and on OUTPUT only, a System.Object or a Progress.Lang.Object
ABL primitive type5	ABL routine (always)9	Any compatible ABL primitive type or any compatible .NET mapped data type (for example, a .NET property) as shown in Table 43,6
ABL array	ABL routine (always)9	A compatible ABL array type6
Progress.Lang.Object	ABL routine (always)9	On INPUT only, any ABL object and any supported .NET object type except a .NET mapped data type4

AS data-type

Indicates an explicit mapping between an argument with an ABL primitive type and the parameter of a .NET method or constructor. Assuming that the .NET data type defined for the parameter is compatible with the data type of the ABL argument, data-type represents an ABL keyword (AS data type) that indicates an alternative .NET data type mapping to identify with the .NET parameter. This option is necessary in the following cases:

• 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.
  Note: You can specify a passed parameter AS data type for a .NET method that is not overloaded. However, you have no need to do so unless the method is overloaded by a given parameter.
• 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).

For the a list of available keywords that you can specify for data-type, as well as the default matches for ABL primitive types with multiple .NET data type mappings, see Table 5 in the Data types reference entry.

Note: The AS data types in Table 5  represent some different data types than you can specify using the AS option to pass a COM method parameter. For more information on passing COM method parameters, see Syntax for accessing COM object properties and methods.

TABLE temp-table-name

Specifies the name of a static temp-table.

This parameter type can match at compile time with any TABLE parameter with the same schema, or any TABLE-HANDLE parameter. If the matching type is TABLE-HANDLE, a run-time check occurs if the TABLE-HANDLE is not the Unknown value (?) in order to ensure that the run-time schemas match. A parameter of a user-defined function or method of a class is verified at compile time, while a parameter of a procedure is verified at run time.

TABLE-HANDLE temp-table-handle

Specifies a handle to a temp-table. Use a temp-table handle as a parameter for a dynamic temp-table. The full schema definition behind the handle and the contents of the temp-table are passed unless the temp-table SCHEMA-MARSHAL attribute is set to minimize or prevent schema marshalling.

This parameter type can match at compile time with any TABLE or TABLE-HANDLE parameter. If the matching type is TABLE-HANDLE, a run-time check occurs if the TABLE-HANDLE is not the Unknown value (?) in order to ensure that the run-time schemas match. A parameter of a user-defined function or method of a class is verified at compile time, while a parameter of a procedure is verified at run time.

DATASET dataset-name

Specifies the name of a static ProDataSet.

This parameter type can match at compile time with any DATASET parameter with the same schema, or any DATASET-HANDLE parameter. If the matching type is DATASET-HANDLE, a run-time check occurs if the DATASET-HANDLE is not the Unknown value (?) in order to ensure that the run-time schemas match. A parameter of a user-defined function or method of a class is verified at compile time, while a parameter of a procedure is verified at run time.

DATASET-HANDLE dataset-handle

Specifies a handle to a ProDataSet. Use a ProDataSet object handle as a parameter for a dynamic ProDataSet. The full schema definition behind the handle and the contents of the ProDataSet object are passed unless the SCHEMA-MARSHAL attribute for one or more of its temp-tables are set to minimize or prevent schema marshalling.

This parameter type can match at compile time with any DATASET or DATASET-HANDLE parameter. If the matching type is DATASET-HANDLE, a run-time check occurs if the DATASET-HANDLE is not the Unknown value (?) in order to ensure that the run-time schemas match. A parameter of a user-defined function or method of a class is verified at compile time, while a parameter of a procedure is verified at run time.

BUFFER buffer

Specifies the name of a buffer.

APPEND

Specifies whether or not to append the source temp-table data to the destination temp-table data. To append OUTPUT parameter data, specify the APPEND option for the parameter in the routine call. To append INPUT parameter data, specify the APPEND option for the parameter in the routine definition.

BY-VALUE | BY-REFERENCE | BIND

Specifies whether to pass a TABLE, TABLE-HANDLE, DATASET, or DATASET-HANDLE parameter by value, by reference, or by binding. The default is BY-VALUE.

You can pass TABLE, TABLE-HANDLE, DATASET, and DATASET-HANDLE parameters to both local and remote procedures. These parameter types are normally passed by value, by default. That is, the calling routine and the called routine each have their own instance of the object, and the parameter is deep-copied from the calling routine's instance to the called routine's instance.

When passing one of these parameters to a local routine, you can override the default in the calling routine by specifying the BY-REFERENCE or BIND option.

Passing one of these parameters to a local routine using the BY-REFERENCE option allows the calling routine and the called routine to access the same object instance. That is, both routines access the calling routine's instance and ignore the called routine's instance. Since the called routine's object instance is ignored, you should define the static object as reference-only by specifying the REFERENCE-ONLY option in the DEFINE statement for the object.

Passing one of these parameters to a local routine using the BIND option allows the calling routine and the called routine to access the same object instance. You can do this by:

• 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

In the static case, you must define a reference-only object in either the calling routine or the called routine by specifying the REFERENCE-ONLY option in the DEFINE statement for the object. You must also define the parameter by specifying the BIND option in the parameter definition.

When you define a reference-only object in the calling routine and pass it to the called routine using the BIND option, the AVM binds the definition of the object in the calling routine to the object instance in the called routine. When you define a reference-only object in the called routine and receive the object from the calling routine, the AVM binds the definition of the object in the called routine to the object instance in the calling routine. In either case, the reference-only object definition remains bound to the object instance until the routine containing the reference-only object definition is deleted or terminates.

Caution:

Do not delete the object or routine to which a reference-only object is bound, or you might be left with references to an object that no longer exists.

You can bind multiple reference-only object definitions to the same object instance. You can also bind a single reference-only object definition to the same object instance multiple times without generating an error. However, you cannot bind a single reference-only object definition to multiple object instances.

When passing one of these parameters to a remote procedure, the AVM ignores the BY-REFERENCE and BIND options and deep-copies the parameter based on the specified parameter mode.

Examples

The following two code fragments show how the AS data type works when calling an overloaded .NET method, in this case the System.Math:Max( ) method. This static .NET method compares two values of the same data type and returns the largest of the two. The first fragment compiles and runs. It compares the value 50, passed as a System.Byte (specified by the AS data type, UNSIGNED-BYTE), with the maximum value of a System.Byte, returned by the System.Byte:MaxValue data member. The result returned by the Max( ) method is 255, the maximum System.Byte value:

DEFINE VARIABLE iVal1   AS INTEGER NO-UNDO INITIAL 50.
DEFINE VARIABLE iVal2   AS INTEGER NO-UNDO.
DEFINE VARIABLE iReturn AS INTEGER NO-UNDO.

iVal2 = System.Byte:MaxValue.
iReturn = System.Math:Max( INPUT iVal1 AS UNSIGNED-BYTE, 
                           INPUT iVal2 AS UNSIGNED-BYTE ).

The second fragment compiles, but returns a run-time error. Again, it passes the same two values to the System.Math:Max( ) method, but this time passes them as a System.SByte (specified by the AS data type, BYTE). A signed byte parameter cannot hold positive values as large as an unsigned byte. So, passing the maximum value of a System.Byte (unsigned byte) as a System.SByte (signed byte) causes the Max( ) method to raise a run-time overflow error:

DEFINE VARIABLE iVal1   AS INTEGER NO-UNDO INITIAL 50.
DEFINE VARIABLE iVal2   AS INTEGER NO-UNDO.
DEFINE VARIABLE iReturn AS INTEGER NO-UNDO.

iVal2 = System.Byte:MaxValue.
iReturn = System.Math:Max( INPUT iVal1 AS BYTE, 
                           INPUT iVal2 AS BYTE ). /* Run-time error */

The following code fragment shows an example of ABL data type widening when passing parameters to a .NET method. This example shows INPUT widening, in this case, passing different ABL data types (INTEGER and INT64) that are acceptable as arguments to a System.Double input parameter:

DEFINE VARIABLE i4Val  AS INTEGER NO-UNDO.
DEFINE VARIABLE i8Val  AS INT64   NO-UNDO.
DEFINE VARIABLE iRoot1 AS DECIMAL NO-UNDO.
DEFINE VARIABLE iRoot2 AS DECIMAL NO-UNDO.

ASSIGN
  i4Val  = System.Int32:MaxValue
  i8Val  = System.Int64:MaxValue
  iRoot1 = System.Math:Sqrt( INPUT i4Val )
  iRoot2 = System.Math:Sqrt( INPUT i8Val ).

For more information on data type widening, see the Notes section later in this reference entry.

Notes

• 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.
  Caution:

  Because the execution order of multiple event handlers subscribed to a single event cannot be guaranteed, if you subscribe more than one event handler to a given class or named event, you cannot be certain which handler will return the values of any parameters that you define for the event.
• 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 4 in the Data types reference entry).

  The following table lists the .NET parameter data types for which ABL supports the widening of ABL data types passed as INPUT arguments. For each .NET parameter data type, the listed ABL implicit mapping data type represents the closest matching ABL data type that you can pass to a .NET input parameter defined with the matching .NET data type. The corresponding listed ABL INPUT widening data types can hold smaller values that might also be acceptable to the .NET input parameter. However, they might also adhere to similar limitations as defined for passing values as the listed ABL implicit mapping data type. (Again, see Table 4 for a more complete description of these limitations.)

  Data types for .NET INPUT parameter widening

  .NET parameter object type	C# parameter primitive type	ABL implicit mapping data type	ABL INPUT widening data type
  System.DateTime	N/A	DATETIME	DATE
  System.Decimal	decimal	DECIMAL	INTEGER, INT64
  System.UInt32	uint	INT64	INTEGER13
  System.Int64	long	INT64	INTEGER
  System.UInt64	ulong	DECIMAL	INTEGER13, INT6413
  System.Double	double	DECIMAL	INTEGER, INT64
  System.Single	float	DECIMAL	INTEGER14, INT6414

• 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 4 in the Data types reference entry).

  The following table lists the .NET parameter data types for which ABL supports the widening of ABL data types passed as OUTPUT arguments. For each .NET parameter data type, the listed ABL implicit mapping data type represents the closest matching ABL data type that can hold a .NET value passed to the OUTPUT parameter defined with the matching .NET data type. The corresponding listed ABL OUTPUT widening data types might hold even larger values than the listed ABL implicit mapping data type. However, but they might also adhere to similar limitations as defined for the listed ABL implicit mapping data type (Again, see Table 4 for a more complete description of these limitations.)

  Data types for .NET OUTPUT parameter widening

  .NET parameter object type	C# parameter primitive type	ABL implicit mapping data type	ABL OUTPUT widening data type
  System.Byte	byte	INTEGER	INT64, DECIMAL
  System.SByte	sbyte	INTEGER	INT64, DECIMAL
  System.Char	char	CHARACTER	LONGCHAR
  System.DateTime	N/A	DATETIME	DATETIME-TZ
  System.Int16	short	INTEGER	INT64, DECIMAL
  System.UInt16	ushort	INTEGER	INT64, DECIMAL
  System.Int32	int	INTEGER	INT64, DECIMAL
  System.UInt32	uint	INT64	DECIMAL
  System.Int64	long	INT64	DECIMAL

• 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.

  For more information on passing class-based objects as parameters between an OpenEdge application server and an ABL client, see the Progress Application Server for OpenEdge: Application Migration and Development Guide or OpenEdge Application Server: Developing AppServer Applications.

• 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 TABLE parameter to a similarly overloaded method or constructor, the AVM executes the method or constructor with a matching TABLE parameter definition. If the AVM cannot identify a method or constructor with a matching TABLE parameter definition, it executes the method or constructor with the corresponding TABLE-HANDLE parameter definition.

  If the AVM cannot locate a method or constructor whose temp-table parameter definitions match the corresponding TABLE-HANDLE or TABLE parameter, the AVM raises a run-time error identifying the ambiguity.

• 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 DATASET parameter to a similarly overloaded method or constructor, the AVM executes the method or constructor with a matching DATASET parameter definition. If the AVM cannot identify a method or constructor with a matching DATASET parameter definition, it executes the method or constructor with the corresponding DATASET-HANDLE parameter definition.

  If the AVM cannot locate a method or constructor whose ProDataSet parameter definitions match the corresponding DATASET-HANDLE or DATASET parameter, the AVM raises a run-time error identifying the ambiguity.

• 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.

See also

Assignment (=) statement, Expression, FUNCTION statement, NEW function (classes), Publish( ) event method, PUBLISH statement, RUN statement, RUN SUPER statement, SUPER statement, SUPER system reference, THIS-OBJECT statement