Specifies the name of an ABL or .NET data type that you can specify as a single instance or as an array of such instances. Thus, an ABL data type can be a built-in primitive type or an array of such primitive types, or it can be a class-based built-in or user-defined object type (such as a class or an interface type) or an ABL array of such object types. A .NET data type can only be a class-based object type (such as a class, structure, enumeration, or interface) or an ABL array of such object types. The EXTENT option, used to define an array of types, is thus counted as part of the array type name.
{ primitive-type-name | object-type-name } [ EXTENT [ constant ] ]
|
[ " ] ABL-object-type [ " ] |
[ " ] dotNET-object-type [ " ]
|
[ "
] ABL-object-type [ "
]
[ package-name . ] class-or-interface-name
|
A period-separated list of text components that, along with class-or-interface-name, uniquely identify an ABL class or interface. These text components specify a package that is based on a valid directory pathname, relative to PROPATH, which identifies the location of the file that defines the class or interface. Thus, each text component of
package-name maps to a directory level in the path, and each slash separator in the path corresponds to a period separating two components.
With the presence of an appropriate USING statement you can also specify an ABL object type that is defined in a package using the
class-or-interface-name without its qualifying
package-name. For more information, see the notes for this reference entry.
If the ABL-object-type has a
package-name that contains embedded spaces, you must enclose the entire
ABL-object-type in quotes (
"). Otherwise, quotes are optional.
[ "
] dotNET-object-type [ "
]
[ namespace . ] dotNET-object-name [ + inner-name ]
|
A period-separated list of text components that, along with dotNET-object-name, uniquely identify a .NET type. The components of
namespace are defined according to .NET requirements. ABL does not support access to .NET types defined in the default namespace. In other words, you cannot access a .NET type that does not have a
namespace defined for it.
If the name part of the dotNET-object-type contains any embedded spaces, square brackets (
[]), or angle brackets (
<>) you must enclose the entire
dotNET-object-type in quotes (
"). Otherwise, quotes are optional.
If your PROPATH is "C:/myfiles", and your class definition file name is "
C:/myfiles/acme/myObjs/CustObjs.cls", then ABL requires
package-name to be "
acme.myObjs." and
class-or-interface-name to be "
CustObjs".
The .NET ControlCollection class is an inner class of
System.Windows.Forms.Control. Therefore, you reference its qualified type name like this:
|
|
Both elements of an ABL object type name (package-name and class-or-interface-name) must conform to the case sensitivity requirements of the operating system (e.g., UNIX or Windows). On a case-sensitive OS, only the first reference to the object type name must be case correct. ABL follows this initial letter case for all subsequent references to the type.
|
|
|
You cannot specify Progress as the first component of package-name for any ABL user-defined class. For example, Progress.Inventory.UpdateInv is an invalid type name for a user-defined class and results in a compiler error.
|
|
|
ABL allows you to name an ABL class or interface using an ABL reserved keyword, such as Display or DISPLAY. For a list of ABL reserved keywords, see the “Keyword Index” section. However, this is not a recommended coding practice, in part because ABL does not fully support the use of static type-name syntax for a class or interface name that is an ABL reserved keyword. This limitation is mitigated if the type name is a fully qualified type name that includes both the package-name and class name.
|
|
|
Depending on the type definition, the context of the type reference, and the presence of an appropriate USING statement, you can use a qualified or an unqualified class or interface name to reference an ABL object type. A qualified type name is one that includes both a package-name and a class-or-interface-name. An unqualified type name is one that includes class-or-interface-name alone, without a package-name. All qualified type names must be fully qualified, using a complete package-name. ABL does not support partially qualified type names using a partial package-name specification. Without an appropriate USING statement, you can only specify an unqualified type name when the type is defined directly on PROPATH (not in a package). In this case, the unqualified type name is the complete type name for the object type.
|
|
|
Depending on the presence of an appropriate USING statement, you can use a qualified or unqualified type name to reference a .NET type. A qualified .NET type name is one that includes both a namespace and a dotNET-object-name. An unqualified .NET type name is one that includes dotNET-object-name alone, without its defined namespace. All qualified .NET type names must be fully qualified, using a complete namespace. ABL (unlike .NET languages) does not support partially qualified type names using a partial namespace specification. Without an appropriate USING statement, you cannot specify an unqualified .NET type name, because ABL does not support access to .NET types that are defined in the .NET default namespace.
|
|
|
When you specify the type name of a class or interface in its ABL type definition statement (CLASS or INTERFACE statement), and the class file where the type is defined resides in a package directory, you must specify the qualified type name ( package-name.class-or-interface-name) for its definition, even with the presence of an appropriate USING statement. You can only specify an unqualified type name ( class-or-interface-name alone) in its type definition statement when the class file defining the type resides directly on PROPATH (is not in a package directory).
|
|
|
ABL allows a locally scoped name (for example, a variable, temp-table, buffer name) to be identical to the name of an accessible class. If this is the case, the locally scoped name takes precedence over any static type-name reference to the unqualified class type name, causing a compiler error on any such reference to a static class member. To avoid this error, ensure that no locally scoped names have the same name as the class, and always either use fully qualified type-name syntax to reference the static class member or use naming conventions to guarantee uniqueness for static member names.
|
|
|
Because of the similarity between the syntax of object-type-name references and table buffer and field references (including similarities between syntax type-name references and field attribute references), ABL can encounter ambiguous references among them, resulting in compilation errors. To ensure that ABL always recognizes object-type-name references unambiguously, either define all object type names with at least three period ( .) separators (in other words, at least three components in any package-name specification) or use naming conventions to guarantee that object-type-name references and database element references are unique. Otherwise, ABL recognizes all such references as object-type-name references.
|
For example, suppose that you have a user-defined class type in your PROPATH, Sports2000.Customer.Name, which defines a static property,
Label. The reference in the following code fragment would then be ambiguous because ABL cannot distinguish between a reference to this static
Label property and a reference to the LABEL attribute on the fill-in widget that is defined for the
Name field in the
Customer table of the
Sports2000 database:
|
Note:
|
The .NET class library does not list nested types as members (which they are) of the type that defines them. Instead, it lists each nested type definition immediately following the type that defines it. You can identify .NET nested types in this listing by the period ( .) that separates the inner-name of the nested type name from the name of the .NET type that defines it. As shown in this syntax and examples, ABL uses a plus ( +) instead of a period ( .) to reference the inner-name of a nested type.
|
|
|
To compile ABL references to a .NET type, the type must be defined in either an automatically-loaded .NET assembly or in a .NET assembly that is listed in an OpenEdge® assembly references file named assemblies.xml. This file must be available either in the working directory or in the directory specified by the Assemblies ( -assemblies) startup parameter. You must also deploy this file at run time. For more information on working with assembly references files, see OpenEdge Development: GUI for .NET Programming. OpenEdge also loads the following assemblies automatically if they are not referenced in assemblies.xml:
|
|
|
Progress.NetUI.dll — Assembly where all custom OpenEdge .NET classes and interfaces reside
|
|
|
Mscorlib.dll — Assembly where all core Microsoft .NET classes and interfaces reside
|
|
|
System.Drawing.dll — Assembly where basic Microsoft graphics classes and interfaces reside
|
|
|
You use the Preload CLR (-preloadCLR) startup parameter to start the current ABL session, which causes the .NET CLR to load at session startup.
|
|
|
The ABL compiler encounters a reference to a qualified object type name, and either that type name matches (or results from a match) to a USING statement containing the FROM ASSEMBLY option or the type cannot be found on PROPATH (meaning that ABL assumes it is a .NET type). This reference can occur on any ABL statement where a type name is used, such as a DEFINE VARIABLE, CAST, static method call, and so on.
|
|
|
You can also specify a constructed .NET generic type for dotNET-object-name. ABL supports references to a .NET generic type for all uses of .NET types except to specify a .NET class to inherit or a .NET interface to implement in an ABL class definition. For more information on constructing and using .NET generic types in ABL, see the Data types reference entry.
|
