Project

General

Profile

Bug #2847

Bug #2677: fix drawing and functional differences between P2J GUI and 4GL GUI

Potential issues in GUI frame layout realized in non-default window

Added by Hynek Cihlar over 8 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
11/13/2015
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:

History

#1 Updated by Hynek Cihlar over 8 years ago

GUI frame layout depends on its parent window. The parent window may be different during frame.openScope() and when the frame is being made visible (in Frame.setVisible()).

Some interesting consequences arise from this:
<ca>
Although forcing doLayout() in setVisible() again might look somehow an overkill, I don't see another approach to adjust the frame (and its content) to its realization window. And another question is: what happens if widget location is interrogated BEFORE the frame is realized, considering (all is implicit layout, no explicit locations):
1. layout from frame.openScope() is done with default/current-window which has a size enough that it fits the entire frame content without i.e. placing the widgets on two or more rows
2. widget location is interrogated before frame is realized
3. frame is realized and drawn on a smaller window
4. widget location is interrogated again
</ca>

Currently the down-body calculated during the first layout is unconditionally thrown away in Frame.setVisible() to satisfy ZeroColumnLayout. This however doesn't seem to be correct because we may loose down-body state calculated from the previous down-body processing.

Also available in: Atom PDF