Release Note 025: Serious issues with GUI for .NET type management in OpenEdge 11.1

While testing the SmartComponent Library and WinKit on OpenEdge 11.1 during the last couple of days, we’ve made a couple of expected code changes but we also ran into two serious OpenEdge regression issues that we are already dealing with Progress tech support and development about.  

Currently we cannot recommend anyone to use OpenEdge 11.1 with GUI for .NET at all!  

We are in the process of further compatibility-testing. We will hopefully be able to release a version of the SmartComponent Library that is compatible with OpenEdge 11.1 soon. At the current our expectation however is, that this will require a hotfix from Progress Software as the issues seem to be related to the type management of the GUI for .NET bridge itself.  

Some details to the issues found so far:  

System.Exception handling

The first ABL regression issue is related to error handling. According to the GUI for .NET documentation .NET Exceptions can be CATCHed using a variable of the ABL Interface Progress.Lang.Error interface.  

“In order to trap and handle .NET Exception objects in common with ABL error objects, OpenEdge has enhanced the .NET System.Exception class to implement the Progress.Lang.Error interface. Implementing this interface allows you to handle all .NET exceptions that are raised in the ABL context by both traditional and structured ABL error handling constructs.”  

While in OpenEdge 11.1 the CATCH still works, passing it as a parameter to other routines (like the Consultingwerk.Util.ErrorHelper:ShowErrorMessage) ends in a runtime error:  

A variable of class ‘System.ArgumentException’ cannot be assigned to a variable of class ‘Progress.Lang.Error’. (13448)  

In OpenEdge 10.2B and OpenEdge 11.0 this still works as expected and documented. The issue in OpenEdge 11.1 causes a serious limitation to how we are able to handle .NET Exceptions in the ABL.  

TYPE-OF malfunction with GUI for .NET hybrid types

The TYPE-OF function seems to misbehave when querying the type compatibility of a reference variable with a GUI for .NET hybrid type that has not yet instantiated.  

Given TypeA and TypeB being two ABL GUI for .NET Forms the following code works fine on OpenEdge 11.0 but fails on OpenEdge 11.1:  

DEFINE VARIABLE oForm AS Progress.Windows.Form NO-UNDO .  

oForm = NEW FormA () .  

MESSAGE TYPE-OF (oForm, FormB)  

VIEW-AS ALERT-BOX.  

oForm is a valid Form reference (containing an instance of FormA). The type-of check for FormB should return FALSE, but it creates a ABL runtime error instead (the source of the error is the GUI for .NET bridge code from Progress):  

System.NullReferenceException: Object reference not set to an instance of an object  

at Progress.ClrBridge.ClrApi.IsTypeOfByName(String type1Name, String type2Name)  

at Progress.ClrBridge.ClrApi.IsTypeOf(Object anObject, String typeName, String qualName, String& objName)  

at Progress.ClrBridge.BrgClrFromPro.isTypeOf(BrgClrFromPro* , Int32 , SByte* , SByte* , SByte* , Int32* )  

Progress.Windows.Form property previousState removed

The Progress Form class does no longer contain the previousState property in OpenEdge 11.1. This property was never intended to be exposed publicly. See the notes about this in the readme.txt file in your OpenEdge 11.1 installation directory.  

We were using this property in the Consultingwerk.Util.FormHelper class which did no longer compile on OpenEdge 11.1. We have removed the code (using conditional compilation) that was using this property. We will investigate an alternative to achieve the same functionality.  

If your code relies on the previousState property, you will have to make appropriate changes to your code as well.  

Actual Instrumentation no longer available in OpenEdge 11.1

Due to the plans to divest the Actional product line, Progress Software does no longer support the Actual Instrumentation and the relevant functionality (include files and ABL class file) are no longer shipped with OpenEdge 11.1. We have therefor removed (using conditional compilation) all references to those include files and classes from our code as well.  

Please contact Progress Software when you have questions or concerns regarding the support for Actional in your OpenEdge application.  

We will keep you updated once we know more!