...
SCL-3302 Fixed Propoarse error when parsing comment ending with ~
Description:
We have fixed an issue in Proparse that was causing failing to interpret source code that contains a single line comment ending with the tilde character (~). Proparse was incorrectly interpreting the tilde to join the following line into the single line comment.
This behaviour is fixed now.
SCL-3316 Fixed query processing error when splitting array fields into separate Fields
Description:
We have fixed a critical regression in the Query Parser of the Data Access classes. The issue was for instance affecting parsing of queries where field names contained the _ character.
Improvement
SCL-3322 Implemented web rendering support for grid's disableTextSelection attribute
Description:
We have added a new Attribute DisableTextSelection in the repository grid setup and rendering support. This attribute controls is text in the Kendo UI Angular grid can be selected (for copy and paste). As that behavior is limiting the grid's row selection capabilities, we've set the default value to FALSE.
SCL-3323 Angular decimal field spinner improvements
Description:
When rendering a decimal field for the Angular UI, we're now rendering the format property to reflect the number of decimal digits defined for the ABL field. So an ABL format with 9 digits, will be rendered as a Kendo UI format of n9.
We have added a new property to the repository called SpinIncrement. This property controls the step size rendered to the Angular text editor component.
The default value is 1. When the value is set to 0, the number of decimal digits of the ABL format string will be used to determine the step size, however, due to limitations of the Kendo UI text box component, the spinner step size will never be smaller than 0.000001. So for an ABL format of 9.99 the step size would be determined at 0.01, for an ABL format of 9.999999999 the steps size would be 0.000001.
New Feature
SCL-2461 Ability to distinguish STOP and STOP-AFTER
Description:
We have now introduced the ability to distinguish between different types of STOP conditions. This feature is based on the ABL's capability to treat STOP conditional more like errors using the constructs of structured error handling. See https://docs.progress.com/bundle/openedge-whats-new/page/STOP-condition-processing.html for details.
This new capability is officially available since OpenEdge 12.0 and was introduced as an unofficial tech-preview in OpenEdge 11.7.4.
To avoid compile errors on OpenEdge releases not supporting the new handling of STOP conditions and to avoid regression issues with customer's applications expecting our legacy handling of STOP conditions the new behavior needs to be turned on in products.i - similar to this here:
| Code Block | ||
|---|---|---|
| ||
&IF 1=0 &THEN
/* Mike Fechner, Consultingwerk Ltd. 02.03.2021
SCL-2461: Support for -catchStop - on OpenEdge 11 */
&ENDIF
&IF NOT PROVERSION BEGINS "11" &THEN
&GLOBAL-DEFINE CATCH-STOP CATCH-STOP
&ENDIF
|
The new behavior is used, when the CATCH-STOP preprocessor has a non blank value.
Previously when our backend was encountering a STOP condition, the ServiceAdapter and ServiceInterface have been handling those using the traditional DO ON STOP construct and returning an instance of the Consultingwerk.Exceptions.StopConditionException to the frontend. This StopConditionException could not be qualified any further (STOP-AFTER, lock wait timeout, R-Code related issues, DB trigger CRC issue, ...). Especially for the STOP-AFTER condition this was really limiting, as STOP-AFTER is more an application feature used to limit long running AppServer requests rather than any sort of critical system issue.
When the new behavior is used, we will no longer handle STOP conditions on the backend (or elsewhere). The Progress.Lang.Stop derived errors are thrown to the caller and can be catched there. A slight exception here are the Count requests in our web handlers. Those utilize the STOP-AFTER feature to limit long running count requests and return a “magic number” when the result cannot be counted in the desired time.
We have extended the ErrorHelper and LogManager classes to provide functionality to deal with the Progress.Lang.Stop derived instances like with Progress.Lang.Error instances (interestingly, Progress.Lang.Error is just an Interface for errors, whereas Progress.Lang.Stop is a class).
We have also extended the Consultingwerk/Windows/ui-catch.i include file to CATCH Progress.Lang.Stop instances as well and invoke the ErrorHelper to display details from those errors.
We're expecting two consequences for customer applications that enable the improved handling of STOP conditions
- code the explicitly catches Consultingwerk.Exceptions.StopConditionException will not catch anything anymore. The CATCH block for this specific error should be replaced (or an additional CATCH block should be added) with a CATCH block for Progress.Lang.Stop.
- event handlers, that only catch Progress.Lang.Error will no longer catch a STOP condition, as the StopConditionException is implementing this error like all AppError derived instances, but Progress has decided that the Progress.Lang.Stop does not.
As the CATCH-Stop feature was not officially released in OpenEdge 11.7, we do not recommend the usage of the -catchStop 1 Startup Parameter to enable this optional feature on OpenEdge 11.7. While we are aware of any issues, we haven't performed intensive tests with the new feature on OpenEdge 11.7.
We recommend any ABL developer to read the Progress documentation on those described changes about the handling of STOP conditions.
SCL-2961 Added support for trapping STOP Conditions in SmartUnit
Description:
SmartUnit now provides better handling of STOP conditions on OpenEdge 12 or OpenEdge 11.7.4 with the -catchStop 1 parameter.
It is now possible to "expect" STOP conditions from Unit Tests by specifying the error class (e.g. Progress.Lang.StopAfter).
When reporting error messages, we're now also distinguishing the various types of STOP conditions.
Customers are recommended to consult the OpenEdge documentation to learn more about the improvements to handling STOP conditions in the ABL.