Bug #6562
Fix displaying of fonts applied to widgets through LOAD+USE or by changing the parent window
Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
06/27/2022
Due date:
% Done:
0%
billable:
No
vendor_id:
GCD
case_num:
version:
History
#2 Updated by Stanislav Lomany almost 2 years ago
- File font-all-widgets.p added
- File test.ini added
- File three windows.png added
- File two windows.png added
- File fonts-changes.diff added
- File font-three.p added
- File test2.ini added
There are three ways how fonts may be applied/changed:
- An .ini file can be loaded at startup by specifying the
ininame
parameter. Loaded configuration effectively replaces the default font table and the default font which defines the size of widgets. This part was implemented for FWD in #4508. - An .ini file can be loaded with
LOAD
and followingUSE
. The new fonts are in effect for windows created afterUSE
call. In this case default font is not changed and therefore the size of elements in most cases stays untouched. Each type of widgets react to fonts differently. By "react" I mean that widget may change its size or not and the new font may be applied or not. Also, widget may be initialized before the parent window is set, e.g. inframe.openScope
so we should explicitly update the widget state. - When a frame changes its parent window, a new font table is applied to the frame. In this case effect is even more limited than in the previous case.
I've attached testcases to demonstrate the issue. Also the screens are attached. To get the same output as on the screens, create deploy/client/test.ini
configuration file with font6
of size=12
and deploy/client/test2.ini
with font6
of size=20, bold
. Sample ini files are attached.
As a part of solution, I suggest to add void notifyWindowChanged(boolean initialPlacement)
function to Widget
interface. initialPlacement
parameter is true
if window is set for a frame for the first time rather than the frame changes the parent window. A diff which implements call of this function is attached.
#3 Updated by Greg Shah almost 2 years ago
Is this describing the way it is supposed to work in the 4GL?
#4 Updated by Stanislav Lomany almost 2 years ago
Is this describing the way it is supposed to work in the 4GL?
Yes.
#5 Updated by Stanislav Lomany almost 2 years ago
The difficulties here:
- The changes should be performed for each widget type individually.
- Existing ways of widget initializations should be changed so font could be changed later.
- Widget size may be defined by one font while the other font is used for drawing.
- Text clipping and positioning issues.