FWD » Core Development » User Interface

1. Any message that results from the fact that a value could not be converted to the combo-box format.
2. **Attribute SCREEN-VALUE for the <widget_type> <widget_name> has an invalid value of <unformatted_value>. (4058)

For GUI combo boxes of type DROP-DOWN or SIMPLE, the value assigned to SCREEN-VALUE is not validated (i.e., whether it can be formatted or whether the formatted value exists among the items) and is simply accepted, so no errors are thrown. The following is true for DROP-DOWN-LIST on GUI and all types (SIMPLE, DROP-DOWN, DROP-DOWN-LIST) on ChUI:

• Value can not be formatted: 1 (ERROR) + 2 (WARNING)
• Value can be formatted, but does not exist in the items: 2 (WARNING)
• Value is empty string
  • no items: no error
  • has items: no error
• Value is unknown value:
  • no items: no error
  • has items: no error

Hynek: Please review 11191a/rev. 16549.

Code review 11191a revisions 16548..16549

• [CRITICAL] style RadioSetWidget: Copyright year in the file header is still 2005-2025, but the file is modified in 2026. Update to 2005-2026, Golden Code Development Corporation.
• [CRITICAL] functional ControlSetEntity.invalidScreenValueWarning: Method dereferences unparsedValue via unparsedValue.isUnknown() with no null check. Concrete trigger: the 3-arg GenericWidget.setScreenValue(ScreenBuffer, Object, boolean) forwards unparsedValue=null to the 4-arg overload; this is exercised on the standard frame realization / DISPLAY path via GenericFrame.copyToScreenBuffer (around line 11301) on a RADIO-SET, SELECTION-LIST or already-realized COMBO-BOX whose value fails isValidScreenValue. The chain reaches validateScreenValue(value, null) which calls invalidScreenValueWarning(null, ...); for RADIO-SET / SELECTION-LIST the realizeCheck=false guard does not bail out, and the method NPEs on unparsedValue.isUnknown(). The old inline implementation referenced only the parsed value (never null), so this is a regression. Add a null guard or fall back to the parsed value when unparsedValue is null.
• [CRITICAL] functional RadioSetWidget.validateScreenValue: Calls invalidScreenValueWarning(unparsedValue, false) when validation fails. Same trigger as above — unparsedValue can be null on the 3-arg setScreenValue path (used during frame realization). With realizeCheck=false and a non-null frame, invalidScreenValueWarning(null, false) immediately NPEs on unparsedValue.isUnknown().
• [MAJOR] functional ControlSetEntity.invalidScreenValueWarning: Replaces ErrorManager.recordOrShowWarning(...) with ErrorManager.displayWarning(...). The two are not equivalent: (a) recordOrShowWarning short-circuits on isSuppressWarnings() and on per-code suppressWarningsSet.contains(num), while displayWarning never consults the per-code suppression set and adds the condition to _MSG even under SESSION:SUPPRESS-WARNINGS; (b) recordOrShowWarning delegates to recordOrShowError which throws DeferredLegacyErrorException when hasLegacyError()/mustManageLegacyError() is true, allowing an enclosing 4GL CATCH Progress.Lang.SysError to capture the condition — displayWarning never throws. Reachable from straightforward 4GL: ASSIGN cb:SCREEN-VALUE = "<invalid>" inside SESSION:SUPPRESS-WARNINGS, with SUPPRESS-WARNINGS-LIST naming 4056/4058, or inside a CATCH block. Verify against OE behavior; if displayWarning is the intended API, the previously suppressed/catchable cases need explicit handling.
• [MINOR] style RadioSetWidget.setScreenValueInt: Continuation lines of the multi-line if condition are indented one column short of the opening condition character, breaking project convention for multi-line condition alignment.
• [MINOR] style GenericFrame.setScreenValue: Newly added Javadoc \@param widget description reads "The widget for which the value is to be retrieved". This is a setter; description must say "set".
• [MINOR] style ControlSetEntity.invalidScreenValueWarning: Both \@param tags use 3 spaces after the tag keyword. All other Javadoc \@param tags in this file and in the same diff use 4 spaces — adjust for consistency.
• [MINOR] style ControlSetEntity.shouldParseScreenValue / ComboBoxWidget.shouldParseScreenValue: Both newly added Javadoc blocks use \@return with 2 spaces. Existing \@return tags in these files use 3 spaces — adjust for consistency.

Instead of getSubType().getValue().equals("DROP-DOWN-LIST") compare the enum value returned by ComboBoxConfig.getMode.

In setScreenValueInt catching ErrorConditionException is used for the happy path. The catch block here is part of the expected flow, not an exceptional condition. Let's turn this into a predicate (e.g. tryParseScreenValue returning a boolean) and reserve the exception for genuinely unexpected failures (or the error condition in this case).

Is the 'UNKNOWN' in invalidScreenValueWarning also displayed in OpenEdge? OpenEdge AFAIK typically represents unknown values as '?' in the messages.

Hynek Cihlar wrote:

Code review 11191a revisions 16548..16549

• [CRITICAL] style RadioSetWidget: Copyright year in the file header is still 2005-2025, but the file is modified in 2026. Update to 2005-2026, Golden Code Development Corporation.
• [CRITICAL] functional ControlSetEntity.invalidScreenValueWarning: Method dereferences unparsedValue via unparsedValue.isUnknown() with no null check. Concrete trigger: the 3-arg GenericWidget.setScreenValue(ScreenBuffer, Object, boolean) forwards unparsedValue=null to the 4-arg overload; this is exercised on the standard frame realization / DISPLAY path via GenericFrame.copyToScreenBuffer (around line 11301) on a RADIO-SET, SELECTION-LIST or already-realized COMBO-BOX whose value fails isValidScreenValue. The chain reaches validateScreenValue(value, null) which calls invalidScreenValueWarning(null, ...); for RADIO-SET / SELECTION-LIST the realizeCheck=false guard does not bail out, and the method NPEs on unparsedValue.isUnknown(). The old inline implementation referenced only the parsed value (never null), so this is a regression. Add a null guard or fall back to the parsed value when unparsedValue is null.
• [CRITICAL] functional RadioSetWidget.validateScreenValue: Calls invalidScreenValueWarning(unparsedValue, false) when validation fails. Same trigger as above — unparsedValue can be null on the 3-arg setScreenValue path (used during frame realization). With realizeCheck=false and a non-null frame, invalidScreenValueWarning(null, false) immediately NPEs on unparsedValue.isUnknown().
• [MINOR] style RadioSetWidget.setScreenValueInt: Continuation lines of the multi-line if condition are indented one column short of the opening condition character, breaking project convention for multi-line condition alignment.
• [MINOR] style GenericFrame.setScreenValue: Newly added Javadoc \@param widget description reads "The widget for which the value is to be retrieved". This is a setter; description must say "set".
• [MINOR] style ControlSetEntity.invalidScreenValueWarning: Both \@param tags use 3 spaces after the tag keyword. All other Javadoc \@param tags in this file and in the same diff use 4 spaces — adjust for consistency.
• [MINOR] style ControlSetEntity.shouldParseScreenValue / ComboBoxWidget.shouldParseScreenValue: Both newly added Javadoc blocks use \@return with 2 spaces. Existing \@return tags in these files use 3 spaces — adjust for consistency.

Instead of getSubType().getValue().equals("DROP-DOWN-LIST") compare the enum value returned by ComboBoxConfig.getMode.

In setScreenValueInt catching ErrorConditionException is used for the happy path. The catch block here is part of the expected flow, not an exceptional condition. Let's turn this into a predicate (e.g. tryParseScreenValue returning a boolean) and reserve the exception for genuinely unexpected failures (or the error condition in this case).

Fixed.

• [MAJOR] functional ControlSetEntity.invalidScreenValueWarning: Replaces ErrorManager.recordOrShowWarning(...) with ErrorManager.displayWarning(...). The two are not equivalent: (a) recordOrShowWarning short-circuits on isSuppressWarnings() and on per-code suppressWarningsSet.contains(num), while displayWarning never consults the per-code suppression set and adds the condition to _MSG even under SESSION:SUPPRESS-WARNINGS; (b) recordOrShowWarning delegates to recordOrShowError which throws DeferredLegacyErrorException when hasLegacyError()/mustManageLegacyError() is true, allowing an enclosing 4GL CATCH Progress.Lang.SysError to capture the condition — displayWarning never throws. Reachable from straightforward 4GL: ASSIGN cb:SCREEN-VALUE = "<invalid>" inside SESSION:SUPPRESS-WARNINGS, with SUPPRESS-WARNINGS-LIST naming 4056/4058, or inside a CATCH block. Verify against OE behavior; if displayWarning is the intended API, the previously suppressed/catchable cases need explicit handling.

• Make the warning be unconditionally added to _MSG, whether SESSION:SUPPRESS-WARNINGS or set or not
• Not display the warning in case of SESSION:SUPPRESS-WARNINGS
• Not throw an actual 4GL legacy error which can be caught by a CATCH block.

As such, displayWarning is the correct API to use here.

Is the 'UNKNOWN' in invalidScreenValueWarning also displayed in OpenEdge? OpenEdge AFAIK typically represents unknown values as '?' in the messages.

Check this testcase:

def var rs as char view-as radio-set radio-buttons "a", "b".
def frame f rs.

rs:screen-value = ?.

Please review 11191a/rev. 16550.

Code review 11191a revisions 16548..16550

The changes look good. Please go ahead with regression testing. Also run ChUI regression tests.

Small regression detected on the testcases project:

define variable rs as logical initial ? format 'one/two' view-as radio-set radio-buttons "first", true, "second", true.
def frame f rs.

rs:screen-value = "".
display rs with frame f.
wait-for window-close of current-window. 

Trunk and 4GL do not raise a warning, meanwhile 11191a does, GUI + ChUI.

Hynek: Please review 11191a/rev. 16624.