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, THROW statement) 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:
- 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.
- 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.
- 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.