USING
{ object-type-name | { package-name | namespace } .* }
[ FROM { ASSEMBLY | PROPATH } ]
|
{ 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.
[ 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.
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:
|
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:
|
|
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:
|
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.
|
|
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.
|
b)
|
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 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.
|
c)
|
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.
|