Try OpenEdge Now
skip to main content
ABL Reference
ABL Syntax Reference : USING statement
 

USING statement

Allows you to reference a single specified ABL or .NET object type, or reference all the types in an ABL package or .NET namespace, using their unqualified type names.

Syntax

USING
  { object-type-name | { package-name | namespace } .* }
  [ FROM { ASSEMBLY | PROPATH } ]
object-type-name
Specifies the qualified type name of a single ABL class or interface, or of a single .NET class, structure, interface, or enumeration. This type name must be the fully qualified type name (including the package or namespace) of an ABL or .NET class or interface type (as described in the Type-name syntax reference entry).
Use this option to identify a single ABL class or interface defined in a package, or a single .NET class, structure, interface, or enumeration defined in a namespace, that you want to reference by its unqualified type name.
The value of object-type-name is restricted to alphanumeric characters plus the symbols #, $, %, and _.
{ package-name | namespace } .*
Specifies an ABL package-name that includes ABL classes or interfaces that you want to reference, or a .NET namespace that includes .NET classes (including structures and enumerations) or interfaces that you want to reference, where an unqualified class, interface, structure, or enumeration name can replace '*' to form a valid fully qualified type name.
Use this option to identify all the ABL classes or interfaces defined in a package, or all the .NET classes, structures, interfaces, or enumerations defined in a namespace, for reference by their unqualified type names.
This expression is restricted to alphanumeric characters plus the symbols #, $, %, and _.
[ FROM { ASSEMBLY | PROPATH } ]
Optionally identifies where to locate a given type definition whose type is being referenced using this statement. This identification permits the ABL compiler to focus its search for the type definition depending on whether the USING statement specifies an ABL package-based type or a .NET namespace-based type. When you specify the FROM ASSEMBLY option, ABL assumes that the type is a .NET type and uses the list of .NET assemblies defined in the assembly identification file to search for the type definition. When you specify the FROM PROPATH option, ABL assumes that the type is an ABL type and uses PROPATH to search for the type definition. If you do not specify a FROM option, the search for a type definition first uses PROPATH, then uses the specified list of .NET assemblies. In most cases, the use of an appropriate FROM option improves compile-time performance.
Caution: Avoid using ABL and .NET class types with the same name. This can cause unpredictable behavior, regardless of whether you specify FROM PROPATH or FROM ASSEMBLY.

Example

You can use either one of the following code fragments to reference the class Acme.BusObjs.Customer using its unqualified or fully qualified class name:
USING Acme.BusObjs.*.

DEFINE VARIABLE CustObj  AS CLASS Customer.
DEFINE VARIABLE CustObj2 AS CLASS Acme.BusObjs.Customer.
USING Acme.BusObjs.Customer.

DEFINE VARIABLE CustObj  AS CLASS Customer.
DEFINE VARIABLE CustObj2 AS CLASS Acme.BusObjs.Customer.
The ControlCollection class is an inner class of the .NET class System.Windows.Forms.Control. Therefore, you can reference these class types by their unqualified type names like this:
USING System.Windows.Forms.* FROM ASSEMBLY.

DEFINE VARIABLE rControl    AS CLASS Control.
DEFINE VARIABLE rCollection AS CLASS Control+ControlCollection.

Notes

*When a type name is referenced at compile time, ABL uses the specified USING statements to help validate that the type exists in a specified package or loaded assembly.
*This statement must appear before any other compilable statement (except other USING statements or the ROUTINE-LEVEL ON ERROR UNDO, THROWstatement) in a procedure (.p or .w) or class definition (.cls) file. The scope of the statement is the file in which it appears.
*This statement has no effect on the object-type-name that defines the name of a user-defined type in a CLASS or INTERFACE statement. In a CLASS or INTERFACE statement, you must always specify the user-defined type that it defines using the fully qualified object-type-name.
*For both ABL and .NET object types, you can only reference class names for classes, interface names for interfaces (and so on) that are defined in the specified ABL package or .NET namespace. For example, you cannot reference partially qualified class names for classes in packages that are further defined under the specified package. To reference the class names of classes in other packages, even those that appear to be subpackages, you must specify an additional USING statement for each package. For example, given the following class file:
C:\Classes\Inventory\Shipping.cls
If you specify the USING statement in this code fragment, the class references in the following statements are invalid:
USING Classes.*.

DEFINE VARIABLE clRef AS Inventory.Shipping. /* Invalid */
clRef = NEW Inventory.Shipping().            /* Invalid */
The following code fragment is correct:
USING Classes.Inventory.*.

DEFINE VARIABLE clRef AS Shipping.
clRef = NEW Shipping().
*You can also reference the fully qualified type names of any object types identified by this statement. You must sometimes do this to avoid ambiguous class or interface name references.
*When you reference a constructed .NET generic type name with the presence of appropriate USING statements, you can also specify the type parameters in its name, as well as the generic type name, itself, using unqualified type name references. This also works to resolve unqualified type-name references to the type parameters specified in the generic object-type-name of successive USING statements. In addition, ABL resolves unqualified type-name references to all the constructed generic types that can be defined for a given namespace specified in a USING statement. For example:
/* 1 */ USING System.Windows.Forms.*.

/* Button is resolved by the first USING statement */
/* 2 */ USING "System.Collections.Generic.List<Button>".

/* 3 */ USING System.Collections.ObjectModel.*.

/* List and Button are resolved by the first two USING statements */
DEFINE VARIABLE ButtonList AS CLASS "List<Button>" NO-UNDO.

/* "Collection<INTEGER>" is resolved by the third USING statement */
DEFINE VARIABLE intColl AS CLASS "Collection<INTEGER>" NO-UNDO.

/* However, this line does not compile */
DEFINE VARIABLE stringList AS CLASS "List<CHARACTER>" NO-UNDO.
Note that unlike the previous DEFINE statement, the final DEFINE statement does not compile, because there is no USING statement specified to resolve references to all possible constructions of the defined open generic type, in this case, System.Collections.Generic.List<T>. Also in this example, Button is a class in the System.Windows.Forms namespace and Collection<T> is a generic class in the System.Collections.ObjectModel namespace. For more information on referencing .NET generic types in ABL, see the Data types reference entry.
*ABL does not validate the definition of type names, packages, or namespaces during USING statement compilation. When ABL later encounters an unqualified object type name following the compilation of all USING statements, it validates this type name against each available object-type-name, package-name, and namespace specified by these USING statements to identify and verify the type definition.
*During procedure or class definition file compilation, ABL resolves all unqualified type name references according to the following algorithm:
1. ABL examines the USING statements in order and, for each statement that specifies a object-type-name, compares the unqualified name with the last node of the object-type-name. If the names are equal, ABL considers this a match and continues compilation with the current USING statement according to its specified FROM option:
*If FROM ASSEMBLY is specified, ABL searches for object-type-name in the loaded assemblies.
*If FROM PROPATH is specified, ABL checks if object-type-name specifies a built-in class or interface type, and if not, ABL searches for a corresponding class file according to the object-type-name package relative to PROPATH.
*If no FROM option is specified, ABL checks if object-type-name specifies built-in class or interface type, and if not, ABL first searches for a corresponding class file according to the object-type-name package relative to PROPATH, then searches for object-type-name in the loaded assemblies.
2. If ABL has not matched the unqualified type name with a object-type-name specified in a USING statement, ABL again examines the USING statements in order. For each USING statement that contains a package-name.* or namespace.*, ABL replaces the "*" with the unqualified name, creating a object-type-name. ABL then continues compilation with the current USING statement according to its FROM option:
*If FROM ASSEMBLY is specified, ABL searches for object-type-name in the loaded assemblies.
*If FROM PROPATH is specified, ABL checks if object-type-name specifies a built-in class or interface type, and if not, ABL searches for a corresponding class file according to the object-type-name package relative to PROPATH.
*If no FROM option is specified, ABL checks if object-type-name specifies built-in class or interface type, and if not, ABL first searches for a corresponding class file according to the object-type-name package relative to PROPATH, then searches for object-type-name in the loaded assemblies.
3. If ABL does not identify a qualified type name from any object-type-name derived from a USING statement, it searches for the unqualified type name reference as a complete ABL type name (defined without a package-name). Thus, ABL searches for an ABL class file with a filename equal to the unqualified type name directly on PROPATH.
If none of these searches identify a valid type definition, ABL generates a compiler error that the type cannot be found.

See also

CLASS statement, INTERFACE statement, Type-name syntax