FWD » Core Development » User Interface

Testcase:

DEFINE VARIABLE edDesc AS CHARACTER VIEW-AS EDITOR
    INNER-CHARS 30 INNER-LINES 3 NO-UNDO font 0.

DEFINE FRAME F-Main
    edDesc AT ROW 2.52 COL 15
    WITH 1 DOWN SIDE-LABELS three-d
    SIZE 80 BY 10.

ENABLE ALL WITH FRAME F-Main.
wait-for close of current-window.

OE:
FWD:

The problem is caused by the order of operations in EditorGuiImpl.initialize(). The scroll pane is initialized and laid out before the editor size is adjusted. Since the editor dimensions are not set yet, the scroll pane inherits a 0x0 dimension. This is considered a valid size, so it does not fall back to the parent dimensions during layout.

The fix is to correct the initialization order: first initialize the scroll pane, then adjust the editor size, and finally lay out the scroll pane.

Hynek: Please review 11303a/rev. 16644.

Code review 11303a revisions 16643..16644

The changes look good to me. Please check the single minor point below.

• [MINOR] functional EditorGuiImpl.adjustSize: On the INNER-CHARS/INNER-LINES path the 3D inset is not applied, so the editor is laid out ~2 px shorter than it should be inside a THREE-D frame. During initialize() the widget is still parentless (WidgetRegistry.reconstructWidget calls initialize() before addWidgetsToFrame), so isThreeD() returns false and line 2100 uses topInset = 1 instead of 2 -- inconsistent with the rule the same file applies in adjustInnerLines() and in the ancestorChanged listener (change 088 / #8835). The corrective ancestorChanged listener is gated on config.heightPixels > 0, and heightPixels is only written by BaseEntity.setHeightPixelsWorker from HEIGHT-PIXELS/SIZE-PIXELS, so it stays 0 for this issue's own reproducer (INNER-CHARS 30 INNER-LINES 3 in a WITH ... THREE-D frame) and the listener body never runs. No later path re-derives it either: afterConfigUpdate() only calls adjustSize(false, true, false) when innerLines/innerChars actually change, and by then config.heightChars is non-zero so explicitSizeSetup is true and the explicit branch re-derives from the already-wrong value. This is a pre-existing sizing inaccuracy, not a regression of this patch -- adjustSize(true) ran equally parentless before the reorder -- but the fix makes it observable for the first time, since the editor is now drawn at all. Recommend a screenshot comparison against OE for the issue's reproducer before closing, and consider relaxing the listener gate to also handle heightPixels == 0 (e.g. re-run adjustSize(false, true, true) on ancestor change).

The minor point does not hold. initialize() does run parentless and uses topInset = 1. However, config.heightPixels is already non-zero (45 in my test) after that initial adjustSize(true) because of the aspect work from SyncCoordinatesAspect.afterSetHeightChars() triggered by the following code:

if (forceEditorChars || config.heightChars == 0.0 || ancestorChanged)
{
   config.heightChars = inCharHeight;
}

, so the ancestorChanged gate passes when addWidgetsToFrame attaches the editor, and the listener re-derives the height with isThreeD() = true (45 -> 47 px). The result matches OE: +2 px in THREE-D frames for static, dynamic and runtime-changed editors. Measured with the help of height attributes and pixel measurements.

As such, if there are no concerns left, I will start testing.

Razvan-Nicolae Chichirau wrote:

As such, if there are no concerns left, I will start testing.

Please go ahead.