Try OpenEdge Now
skip to main content
GUI for .NET Primer
GUI for .NET Environment : .NET Framework
 

.NET Framework

The OpenEdge GUI client supports the ability to access Microsoft .NET objects from ABL much as if they were native ABL objects. ABL access to .NET objects is designed to support the OpenEdge GUI for .NET, which provides an alternative Windows desktop user interface for ABL applications based on .NET Windows Forms forms and controls. ABL enables your application to use the GUI for .NET together with the traditional OpenEdge GUI, and provides particular support for using .NET forms and ABL windows together in the same ABL session.
ABL provides access to objects in a .NET class library. The following figure shows that all class-based objects in ABL are derived from the Progress.Lang.Object root class.
Figure 1. .NET Class Inheritance Stack
ABL supports .NET controls within ABL. ABL can interact with .NET objects using enhanced ABL features without, itself, becoming a native .NET language. This allows you to continue to use ABL as you have in previous OpenEdge releases. References to .NET controls in ABL are made using object-oriented (OO) syntax. You can make those references from procedural or class-based code or any combination.
The following figure represents the OpenEdge GUI for .NET architecture at a high level. In support of .NET objects and events, ABL incorporates the ABL Virtual Machine (AVM) and the .NET Common Language Runtime (CLR) within a single OpenEdge client process. The CLR is the core run-time engine for executing applications in the Microsoft .NET Framework.
What makes communication between the ABL and .NET possible is the bridge that provides the transformation by allowing information to go back and forth between the AVM and the CLR. When the CLR gets a request, such as to run a .NET method, the bridge converts the data between the CLR and the AVM.
On the AVM side you define your components, do your data access, do I/O blocking (a version of the WAIT-FOR statement), and write event handlers in ABL. On the .NET side, the CLR handles the visualization of the .NET UI. The user interacts with the CLR, because that is where the user interface is running.
Figure 2. OpenEdge GUI for .NET Architecture
The figure above depicts a simplified sample flow of control between the AVM and the CLR:
1. In ABL, a new .NET form is created. The form subscribes an ABL event handler method to its FormClosing event, and the form is run.
2. The request is passed over the bridge to the CLR to create the .NET form.
3. The form is displayed using a .NET method specified by the WAIT-FOR statement.
4. The user does some work and closes the form.
5. The FormClosing event message is sent to all subscribers from .NET.
6. The bridge sends the message to the AVM and causes the event handler method to run.
There is no one application architecture supported by GUI for .NET. You can either keep your existing architecture or follow a modularized design such as the OERA. There is no requirement to change your application architecture, though some applications might require more modifications than others to provide a GUI for .NET interface that communicates with existing data management and business logic. There might be compelling reasons to update parts of your application architecture to take advantage of advanced features that GUI for .NET provides. Many architectural topologies are supported, including fat client, client/server, and n-tier. GUI for .NET does not require you to change from one topology to another.
Just as there is no one UI technology that is applicable for all of today's applications, an application's primary use often dictates what UI technology works best. To put GUI for .NET development in perspective, it helps to compare this technology with other OpenEdge UI technologies.
The following table lists the various OpenEdge UI technologies, their primary use, and what development tools are best suited for building these types of business applications. These are suggestions; the table is not meant to be all-inclusive and there is overlap between technologies, their primary use, and tools.
Table 1. OpenEdge UI technologies
UI Technology
Primary Use
Tools to Use
GUI for .NET
Build modern, state-of-the-art GUIs for Microsoft Windows in ABL
Progress Developer Studio for OpenEdge Visual Designer
OpenEdge GUI
Build Windows 95 user interface look and feel
OpenEdge StudioProgress Developer Studio for OpenEdge AppBuilder, Editor
Open Client
Build alternate UIs (.NET & Java™) to OpenEdge applications, requires AppServer
Open Client Toolkit
WebSpeed®
Build web-browser based applications with zero client footprint
WebSpeed Workshop
Character
Build traditional green-screen user interfaces
OpenEdge StudioProgress Developer Studio for OpenEdge Editor4GL Development System
WebClient can be used as a deployment platform for OpenEdge GUI, GUI for .NET, and Character UIs.