When to use the call object

For some use cases, programming with the call object requires more lines of code than other ABL alternatives. The following table shows an example of the code required to invoke an external procedure dynamically and statically.

Table 1. Invoking hello.p dynamically and statically
Dynamic invoke Static invoke 
DEFINE VARIABLE hCall AS HANDLE
  NO-UNDO.

CREATE CALL hCall.

/* Invoke hello.p non-persistently */
ASSIGN
  hCall:CALL-NAME      = "hello.p"
  hCall:NUM-PARAMETERS = 1.

hCall:SET-PARAMETER (1, "CHARACTER",
  "INPUT", "Hello world").

hCall:INVOKE( ).

/* Clean up */
DELETE OBJECT hCall.
 
RUN hello.p ("Hello world").

As the previous table illustrates, executing hello.p dynamically using the call object requires many more lines of code and is therefore less efficient than doing it with static invoke.

Consider using the call object for these situations:

  • To invoke an internal or external procedure whose calling sequence (number of parameters and the data type of each) is unknown at compile time.
    Note: If the only the name of the procedure is unknown at compile time, use the RUN statement with the VALUE option, and avoid using the call object.
  • To invoke a function whose calling sequence is unknown at compile time
    Note: If the only the name of the function is unknown at compile time, use the DYNAMIC-FUNCTION( ) function, and avoid using the call object.
  • To reference a widget attribute or method whose name is unknown at compile time.

    If you already know the name of the attribute or procedure, then you also know its syntax, since the name implies certain syntax. If you know the syntax, then you know the calling sequence, since the syntax defines the calling sequence. If you know the calling sequence, you can use widget:attribute or widget:method syntax, and avoid using the call object.

  • To dynamically invoke a Windows DLL routine or a UNIX shared library routine when the following is true:
    • The number of parameters and their data type is only known at run time
    • The routine exists in both a Windows DLL and a UNIX shared library
    • The routine has a variable number of parameters