ABL allows you to use an ABL class to derive (create a subclass of) many .NET classes, including abstract classes, with some restrictions. For more information on these restrictions, see Limitations of support for .NET classes.
As described previously (see Incorporation of the .NET object model), when an ABL class inherits from a .NET class, it appears at the bottom of the .NET class hierarchy exactly like any .NET class that inherits from the same hierarchy. This means that an ABL-derived .NET class inherits the same protected and public members in the .NET class hierarchy that a .NET derived class does (see Accessing .NET class members), including:
Fields (data members)
Methods
Properties
Events
Nested (inner) types
Static fields (data members)
Static properties
Static methods
Static events
When an ABL class derives a .NET class, it can modify the data and behavior of the base class by:
Overriding non-abstract instance methods inherited from the .NET class hierarchy with its own ABL OVERRIDE instance methods. For more information, see Overriding.NET methods.
Publishing events inherited from the .NET base class by calling methods that are typically defined for this purpose and inherited along with each event. For more information, see Managing events for ABL-derived .NET classes.
Extending the .NET base class with its own ABL data members, properties, methods, and class events, including the overloading of inherited .NET methods. Such additional ABL class members can be added in exactly the same way as in a pure ABL class. However, these extended ABL members are only available to the ABL context and are not visible to the .NET context.
An ABL class cannot implement the following .NET modifications as part of deriving a .NET class:
Overriding non-abstract properties and events — In .NET, a derived class can override non-abstract properties, methods, and events inherited from a super class. However, an ABL-derived .NET class can only override non-abstract methods inherited from a .NET super class (see Overriding.NET methods).
Hiding non-abstract members — Hiding is a concept in .NET where a subclass can redefine a member of a super class without overriding it, by essentially replacing the inherited definition with a new one (using the new keyword in C#). ABL does not support the hiding of super class members, whether or not they are inherited from ABL or .NET. Any attempt to define a new member with the same name as non-abstract super class member results in a compile-time error, unless it is to explicitly override a method.
So, when an ABL application instantiates an ABL-derived .NET class, it can access all the supported public .NET class members on the ABL-derived instance, including subscribing to inherited .NET events. It can also access any PUBLIC ABL data members, properties, methods, and events defined by the ABL-derived class, including any non-abstract .NET methods that are overridden or overloaded by these ABL methods and any abstract .NET properties, methods, and events that are implemented by corresponding ABL properties, methods, and events.
ABL also supports polymorphic access to ABL-overridden .NET methods and ABL-implemented .NET abstract properties, methods, and events from both the ABL and the .NET run-time contexts. While .NET does not know about any ABL extensions, it can still use the ABL-extended class instance as it does the .NET super class or interface. If either .NET or ABL calls an ABL-overridden method on a super class reference to the ABL-derived instance, ABL ensures that the most derived method in the hierarchy (in this case, the overriding ABL method) is called. The same is true if either .NET or ABL calls an ABL-implemented abstract property method, or event. For more information on how the ABL and .NET run-time contexts interact, see GUIfor .NET run-time architecture.
Fields (data members)