10.1B release note review

Some interesting notes from the 10.1B release notes (oe_101b_readme.pdf on PSDN). This is only from the ABL & OO sections of the release.

A dynamic query with a RECID in a WHERE clause from a 10.1A client connecting to a 10.1B server will fail.

RN#: 101B-00086

===============

A dynamic query with a RECID in the WHERE clause from a 10.1A client and a 10.1B server will fail. This is due to the fact that 10.1B RECIDs are 64 bit versus the 10.1A and previous RECIDs which are 32 bit. This is only a problem with RECIDs which have been deprecated. A workaround to this is to use ROWID or the buffer method FIND-BY-ROWID.

STOP condition not handled properly in class methods.

RN#: 101B-00113

======================================

In 10.1B a STOP condition that is raised within a method of a class is not handled properly by the Progress runtime. The STOP will be caught by the closest ON ERROR block, rather than the closest ON STOP block. If the ON ERROR block causes a retry, there may be a crash. It is possible that code that worked in 10.1A may fail in 10.1B with this problem. The problem does not occur if the statement that invokes the method includes the NO-ERROR option or if an ON STOP block is coded inside the method that raises the STOP condition.

INT Not Supported for ActiveX in Release 10.1B

RN#: 101B-00126

===============

Release 10.1B does not contain any support for using the INT64 datatype with ActiveX controls or ActiveX Automation objects. This is contrary to the documentation, which says that it is supported. This means that if you try to pass an INT64 datatype as a parameter to a COM object the results are unpredictable. It may cause an error. This is true even if it is an input parameter and the number in the variable is within the 32-bit range. Therefore, you should not use the INT64 data type with COM objects and therefore cannot expect to be able to get back a 64-bit number correctly from a COM object.

Cached class definitions may become stale

RN#: 101A-00093

================

During the development of an application that utilizes user-defined classes, compilation results may not reflect changes to the class file made during the current development session. For example, the compiler may not recognize changes made to a referenced class, or it may not recognize changes made to a super class in a hierarchy. In particular, this may happen if you run your application and make changes in the same Procedure Editor session. If you encounter this problem the workaround is to restart the development session and remove any r-code that was generated for these classes.

Recommended approach when compiling changes to a super class

RN#: 101A-00334

===============

When you change a super class, you also must recompile all subclasses of the super class to ensure that all objects built from the super class inherit the updated data or behavior. Progress, by itself, has no knowledge of these subclasses, so you must keep track of them manually or by using configuration management tools.

Use of PUBLIC data members via an object reference

RN#: 101A-00335

===============

An application can access a PUBLIC data member via an object reference in the same places that an application can use attributes on Progress built-in objects. An application can access PUBLIC data member in expression, but it is invalid to use one in place of a program variable. For example, the following statement is

invalid:

RUN myProg PERSISTENT SET myObjectRef:publicHandle.

This statement should be written as:

RUN myProg PERSISTENT SET myLocalHandle.

myObjectRef:publicHandle = myLocalHandle.

[This is consistent with the restriction that one can't do this either:

ASSIGN

obj1 = NEW class-name

obj2 = NEW class-name

.

"assignment" to class instances - and apparently data members - doesn't seem to've been implemented the same way as a assignment to a variable.

]

COMPILE XREF output for METHOD reference type

RN# 101A-00354

======================================

COMPILE with the XREF option will produce an XREF output file that includes entries for PUBLIC and PROTECTED method definitions. In 10.1A it also included entries for PRIVATE method definitions. In 10.1B these entries are no longer included in the XREF output.

Functions that return INT64 may require some changes to class methods.

RN#: 101B-00090

======================================

In 10.1A the following functions returned INTEGER: CURRENT-VALUE, DYNAMIC-CURRENT-VALUE, DYNAMIC-NEXT-VALUE, ETIME, GET-POINTER-VALUE, GET-SIZE, INTERVAL, NEXT-VALUE, and SEEK. In 10.1B these functions have been modified to return INT64. 10.1A class methods that are written to return INTEGER and return one of these functions will no longer compile in 10.1B. The method must be modified to return INT64 or an intermediate INTEGER variable can be used to store the value of the

PRIVATE methods must be defined before they are reference

RN#: 101B-00094

======================================

When defining a class it is not necessary to define PROTECTED and PUBLIC methods before they are used. These method definitions can occur anywhere in the class definition. This is not the case with PRIVATE methods, which must be defined before they are referenced anywhere in the class definition.

Error sometimes not caught when a CREATE or RUN statement that sets a handle fails.

RN#: 101B-00096

======================================

A RUN statement may include the SET option for setting a handle to a persistent procedure, a Web Service PortType, or an Asynchronous Request. If the RUN itself creates an error condition (for example, a procedure executes a RETURN ERROR from Block 0), the runtime will not detect the error if the handle variable to be set is a SHARED variable, an array element, a class property, or a class data member. If an attempt to CREATE a widget or similar ABL object fails, the error

will not be caught if the handle variable is one of these types. In all of these cases, the ERROR-STATUS system handle will not be populated correctly even if the statement includes NO-ERROR. If the statement does not include NO-ERROR, the runtime will execute the next statement rather than observe the error processing in effect for the current block.

RETURN ERROR from VOID method not caught by the calling method

RN#: 101B-00123

===============

If a VOID method executes a RETURN ERROR, error gets raised in the method that invoked the VOID method. However it is not caught and reset by the implicit ON ERROR block of the method. Instead it remains in effect until the nearest ON ERROR block (either implicit or explicit) in a procedure is encountered. This only occurs if the method invoked is a VOID method, if it is invoked from another method, and if error is raised via RETURN ERROR.

Cannot use RETURN ERROR and DELETE OBJECT THIS-OBJECT in the same constructor.

RN#: 101B-00124

===============

If a constructor contains both a RETURN ERROR statement following a DELETE OBJECT THIS-OBJECT statement unexpected behavior may occur. RETURN ERROR accomplishes the same work as DELETE OBJECT THIS-OBJECT and additionally raises error on the NEW phrase. There is no benefit to using both statements and it is not recommended.