FWD » Core Development » User Interface

There is a bug in FWD where the height of a dialog-box window is not computed correct, when frame's height is set explicitly by the business logic:

def var i as int.

form i with frame f1 side-labels title "f1" view-as dialog-box size 20 by 10.

message frame f1:height-pixels frame f1:width-pixels.

on "1" anywhere do:
  frame f1:height-pixels = 120.
end.

update i with frame f1.

Also, as dialog-box frame's height can be resized by the business logic, ensure this works properly, too.

Constantin, can you be more specific, what is the expected result of the sample code above? I didn't find any issues related to the dialog-box window size.

What I did found was a wrong non-dialog-box frame inner (scrollable) size, the frame title was not properly accounted for. This is fixed and I am just committing the code changes.

Another problem related to the inner frame size is when frame size is changed (in the trigger above). In native 4GL the outer size changes but the inner size stays intact, however in FWD both inner and outer sizes do change. This issue exists for dialog-box frames as well as regular frames. This isn't fixed.

The incorrect size turned to be a problem in the frame layout itself. The frame height is not calculated correctly when the order the widgets are declared in the frame doesn't follow the y location. The following sample demonstrates the issue.

DEFINE BUTTON b1.
DEFINE VARIABLE f1 as character VIEW-AS FILL-IN.
DEFINE FRAME fr b1 AT ROW 3 col 5 f1 AT ROW 1 col 5 WITH SIDE-LABELS.
enable all with frame fr.
wait-for close of this-procedure.

The fix is in 3368a. Regression testing is in progress.

Code Review Task Branch 3368a Revision 11203

I'm fine with the changes, except it is not clear why the null check was removed from FrameGuiImpl.

Greg Shah wrote:

except it is not clear why the null check was removed from FrameGuiImpl.

The null check was incorrect, it caused the method to return incorrect value when it was called during frame init phase. At the time the font resolver wasn't set. Since it wasn't needed anyway, I just removed it.

3368a revision 11204 includes code comment describing the above as well as the missing file history entries.

Code Review Task Branch 3368a Revision 11204

I'm fine with the code. If it passes regression testing, you can merge to trunk.

3368a revision 11205 contains a small change that resolves a regression found during ChUI testing. The revision has passed both GUI and ChUI regression tests and is ready to be checked in if review OK.

Code Review Task Branch 3368a Revision 11205

The changes are good. You can merge to trunk.

3368a was merged in trunk as revision 11202 and archived.