Bug #10242
Editor content placed too high
0%
History
#1 Updated by Delia Mitric about 1 year ago
Here is a testcase:
DEFINE VARIABLE ed1 AS CHARACTER
VIEW-AS EDITOR NO-BOX
SIZE 39.2 BY .62 NO-UNDO.
DEFINE VARIABLE fi1 AS CHARACTER FORMAT "X(256)":U
LABEL "Label text"
VIEW-AS TEXT
SIZE .2 BY .62 NO-UNDO.
DEFINE FRAME fMain
ed1 AT ROW 1.81 COL 20.8 NO-LABEL WIDGET-ID 2 NO-TAB-STOP
fi1 AT ROW 1.81 COL 18.4 COLON-ALIGNED
WITH 1 DOWN
SIDE-LABELS THREE-D
AT COL 1 ROW 1 SIZE 60 BY 5 SCROLLABLE.
ENABLE ALL WITH FRAME fMain.
ASSIGN
ed1:READ-ONLY IN FRAME fMain = TRUE.
ASSIGN
fi1:READ-ONLY IN FRAME fMain = TRUE.
ASSIGN ed1:SCREEN-VALUE IN FRAME fMain = "This is the editor content.".
WAIT-FOR CLOSE OF CURRENT-WINDOW.
How many pixels higher the editor content is depends on the font used. (See #10126)
#2 Updated by Delia Mitric about 1 year ago
Eugenie, I have a question..
Do we need to keep the artificial modality of calculating the fontDescent and refine it (like find a better formula) or to use font.descent (don't know where to find it )?
#3 Updated by Eugenie Lyzenko about 1 year ago
Delia Mitric wrote:
Eugenie, I have a question..
Do we need to keep the artificial modality of calculating the fontDescent and refine it (like find a better formula) or to use font.descent (don't know where to find it )?
Taking the descent from Java/JS code can become performance trouble because extra processing and dependency on particular font instance. The usage of the generic formula is better and more predictable approach I think. But the artificial formula may need to be improved depending on GUI results we have.