Class-based method call

Invokes a method of a class. If the method returns a value, the method call can appear anywhere that an expression can appear, and it can also appear as a single statement, ignoring the return value. If the method is VOID (does not return a value), the method call must appear as a single statement.

Syntax


[ { `class-type-name` \| `object-reference` } : ] `method-name` ( [ `parameter` [ , `parameter` ] ... ] ) [ NO-ERROR ]

class-type-name

The name of an ABL or .NET class type that defines the specified method as a static member. The use of class-type-name to call a static method is optional when you call the method from within the class hierarchy where it is defined. For more information, see the notes for this reference entry. You cannot use class-type-name to call an instance method. For more information on specifying class (object) type names, see the Type-name syntax reference entry. You can use the unqualified class name with the presence of an appropriate USING statement.

object-reference

Specifies a reference to an ABL or .NET class instance (an object) that defines the specified method as an instance member. The use of object-reference to call an instance method is optional when you call the method from within the class hierarchy where it is defined. For more information, see the notes for this reference entry. You cannot use object-reference to call a static method. For information on specifying object references, see the reference entry for a Class-based object reference.

method-name

Specifies the name of an ABL or .NET class method you want to call. A class method is a named block of ABL or .NET code, similar to a procedure or user-defined function, that is defined in a class. An instance method is available for an instance of the class for as long as the class instance exists. A static method is available for the defining class type during the entire ABL session, regardless if an instance of the class exists. A class method is available inside or outside of the class hierarchy depending on its access mode.

( [ parameter [ , parameter ] ... ] )

Specifies zero or more parameters passed to the method. You must provide the parameters identified by the specified method, matched with respect to number, data type, and mode. To invoke a method that is overloaded in the class, you must specify sufficient information for each parameter in order to disambiguate methods that have similar parameter lists. Otherwise, the AVM raises an error identifying the ambiguity.

For more information on parameter passing syntax and on disambiguating overloaded ABL and .NET methods, see the Parameter passing syntax reference entry.

NO-ERROR

Suppresses ABL errors or error messages that would otherwise occur and diverts them to the ERROR-STATUS system handle. If an error occurs, the action of the statement is not done and execution continues with the next statement. If the statement fails, any persistent side-effects of the statement are backed out. If the statement includes an expression that contains other executable elements, like methods, the work performed by these elements may or may not be done, depending on the order the AVM resolves the expression elements and the occurrence of the error.

To check for errors after a statement that uses the NO-ERROR option:

Check the ERROR-STATUS:ERROR attribute to see if the AVM raised the ERROR condition.

Check if the ERROR-STATUS:NUM-MESSAGES attribute is greater than zero to see if the AVM generated error messages. ABL handle methods used in a block without a CATCH end block treat errors as warnings and do not raise ERROR, do not set the ERROR-STATUS:ERROR attribute, but do add messages to the ERROR-STATUS system handle. Therefore, this test is the better test for code using handle methods without CATCH end blocks. ABL handle methods used in a block with a CATCH end block raise ERROR and add messages to the error object generated by the AVM. In this case, the AVM does not update the ERROR-STATUS system handle.

Use ERROR-STATUS:GET-MESSAGE( message-num ) to retrieve a particular message, where message-num is 1 for the first message.

If the statement does not include the NO-ERROR option, you can use a CATCH end block to handle errors raised by the statement.

Some other important usage notes on the NO-ERROR option:

NO-ERROR does not suppress errors that raise the STOP or QUIT condition.

A CATCH statement, which introduces a CATCH end block, is analogous to a NO-ERROR option in that it also suppresses errors, but it does so for an entire block of code. It is different in that the error messages are contained in a class-based error object (generated by the AVM or explicitly thrown), as opposed to the ERROR-STATUS system handle. Also, if errors raised in the block are not handled by a compatible CATCH block, ON ERROR phrase, or UNDO statement, then the error is not suppressed, but handled with the default error processing for that block type.

When a statement contains the NO-ERROR option and resides in a block with a CATCH end block, the NO-ERROR option takes precedence over the CATCH block. That is, an error raised on the statement with the NO-ERROR option will not be handled by a compatible CATCH end block. The error is redirected to the ERROR-STATUS system handle as normal.

If an error object is thrown to a statement that includes the NO-ERROR option, then the information and messages in the error object will be used to set the ERROR-STATUS system handle. This interoperability feature is important for those integrating code that uses the traditional NO-ERROR technique with the newer, structured error handling that features error objects and CATCH end blocks.

To access more comprehensive error information for a .NET exception, use a CATCH end block instead of the NO-ERROR option. For more information on handling .NET exceptions, see the sections on .NET error handling in OpenEdge Development: GUI for .NET Programming.

Examples

The following code fragment shows a call to a public instance method (SetHighCustomerData( )) on an instance of the sample class, r-CustObj:


DEFINE VARIABLE `rObj AS CLASS r-CustObj` NO-UNDO. `rObj = NEW r-CustObj( )` NO-ERROR. `rObj:SetHighCustomerData( )` NO-ERROR.

This instance method initializes instance data for the class.

The following code fragment shows a call to a public static method (SetHighCustomerData( )) on the sample class type, r-CustObjStatic:


`r-CustObjStatic:SetHighCustomerData( )` NO-ERROR.

This static method initializes class static data without having to instantiate the class, as in the previous instance code.

For more information on these methods and the sample classes in which they are defined, see the examples in the CLASS statement reference entry.

Notes

Using the appropriate syntax, you can invoke the method as a statement (without returning a value) or invoke the method in an expression that uses the defined return value according to its data type. For information on ABL methods and their definition, see the METHOD statement reference entry. For information on the definition of a .NET method, see its entry in the Microsoft .NET, Infragistics, or other class library that defines it. For information on how .NET data types map to ABL data types, see the Data types reference entry.

If the method is defined as static, you can call the method whether or not an instance of its defining class exists.

If you reference an available method within a static constructor, static method, or static property accessor that is defined in the same class or class hierarchy as the referenced method, the referenced method must also be defined as static; attempting to directly reference an instance method that is defined in the same class or class hierarchy as the referencing static member raises a compile-time error.

You cannot use a class instance that is not equal to the THIS-OBJECT system reference to call a private or protected instance method that is defined in the same class, even though this method is defined in the instantiating class definition. In ABL, all private and protected methods are instance based and available only to members of a given instance of the class, including (for static methods) the "static instance" in the ABL session.

From within an ABL class definition, you can typically invoke any instance method that is defined and available within the class hierarchy by referencing its method-name and any parameter list without a qualifying object-reference. However, if the method name is a reserved keyword, you must call the method using THIS-OBJECT as the object-reference. If the instance method is defined as an OVERRIDE method, you can invoke the method implementation that it overrides in the most derived class where it is defined using SUPER as the object-reference. For more information, see the reference entry for the SUPER system reference.

From within a class definition, you can typically invoke any static method that is defined and available within the class hierarchy by referencing its method-name and any parameter list without a qualifying class-type-name. However, if the method name is a reserved keyword, you must call the method using the qualifying class-type-name, even if the method is called from within the class that defines it. If the static method is defined as an OVERRIDE (redefining) method, you can invoke any static method implementation in the class hierarchy that it redefines by using the qualifying class-type-name of the class that defines the particular method implementation you want to call.

From outside a class hierarchy, you can only invoke an available instance method by referencing its method-name and its parameters qualified by an object-reference to the class instance where the method is defined; you can only invoke an available static method by referencing its method-name and its parameters qualified by the class-type-name of the class that defines the method as static. The only methods defined within a class hierarchy that are available outside the hierarchy are methods defined as PUBLIC.

You can call an abstract method either from within the class that defines it or on an object-reference defined as the type of the abstract class that defines it. Although an abstract method is defined without an implementation, at run time, the method is always implemented in a derived class. So, any reference to an abstract method is always resolved by the most derived class that implements it.

ABL has the following limitations on the .NET methods you can call:

You cannot call the static method, System.Windows.Forms.Application:DoEvent( ). In ABL, you can use the PROCESS EVENTS statement to handle both ABL and .NET events.

You cannot call the static method, System.Windows.Forms.Application:Run( ), outside of a WAIT-FOR statement. For more information, see the WAIT-FOR statement (.NET and ABL) reference entry.

You cannot call the instance method, System.Windows.Forms.Form:ShowDialog( ), outside of a WAIT-FOR statement. For more information, see the WAIT-FOR statement (.NET and ABL) reference entry.

You cannot call a .NET generic method. Similar to a .NET generic type, a .NET generic method has a name that is appended with a comma-separated list of one or more type parameters enclosed in angle brackets, for example, Add<T, S>(tVar, sVar). In this case, you would substitute .NET data types for the parameters T and S when you called the method. ABL does not currently support any reference to these methods. For more information on ABL support for .NET generic types, see the Data types reference entry.