FWD » Core Development » User Interface

Hynek Cihlar wrote:

It seems the lifetime of the FULL-WIDTH-CHARS value is a bit more complex. I did a few simple tests and here are some early findings:

• FULL-* attribute returns unknown value for a new window (after create window h) before it is made visible.
• FULL-* attribute returns valid value for a new window after it is made visible.
• FULL-* attribute returns a valid value default-window, even before it is made visible. I tested this with running the procedure file directly with prowin without showing the procedure editor.

So I'm not sure the init() method is the right place.

Created task branch 3548a from trunk revision 11246.

Currently I see two deviation for FWD comparing to 4GL:

1. The default window attribute values are unknown (?) when should be properly initialized. No matter if it is visible or not.
2. The attribute values are valid for created but not yet visible dynamic window when the correct value is unknown (?).

The testcase is win_full_hw_attr.p.

Task branch 3548a has been rebased with recent trunk and updated for review to revision 11248.

This is the base fix for deviations found for this issue. The default window set up early enough (even before it is visible). The dynamic windows has now unknown values before realization and valid values when become first time visible.

Now testing in Windows OS to get correct values to FULL-* attributes. To exactly compare what values we have in both 4GL and FWD.

Task branch 3548a has been updated for review to revision 11249.

Two more changes here:

1. I've accidentally found the abend issue (-2 as array index exception) in EditorGuiImpl for mouse click.

2. The issue related change is to eliminate deviations for full size window attributes. New method has been added to separate calculation. It works good for dynamic window that has all internal defined before update full size attributes (just before first painting). However the default window behaves differently and valid FULL-* attributes become problematic at the moment when window is not yet visible. We need to set up the values when not available all decorations have been initialized. The status line and message area are the examples. The FULL-* attributes are computing in ThinClient.initializePost() code and we can either take into account some average values for status and message heights or to choose another moment to compute FULL-* attributes for default window. Continue investigation.

Task branch 3548a has been updated for review to revision 11250.

This is the small typo fixes for file headers info records.

Code review task branch 3548a revision 11250.

WindowGuiImpl.fullSizeAttributesUpdated is redundant. Just move the call updateFullSizeAttributes to WindowGuiImpl.init at the end of the body and protect it with if (!getId().equals(WidgetId.DEFAULT_WINDOW_ID)).

WindowChuiImpl.initDefaults() is redundant, there is already no-op body Window.initDefaults().

ThinClient.initializePost(), default window may be used before the environment is fully initialized (see DefaultLoginPanel for example) so the call to initDefaults() should be better moved to WindowManager.getDefaultWindow().

Task branch 3548a has been updated for review to revision 11251.

This is reworked code with changed location to get default window FULL-* attributes. No changes in ChUI code, no changes in ThinCLient - all this was undone. Only GUI code is now affected. And this is release candidate on my guess.

Code review 3548a revision 11251.

The changes are good. But note that the value of the FULL-* attribute changes when the window layout changes. For example when a menubar is made visible or hidden.

Hynek Cihlar wrote:

Code review 3548a revision 11251.

The changes are good. But note that the value of the FULL-* attribute changes when the window layout changes. For example when a menubar is made visible or hidden.

Task branch 3548a has been updated for review to revision 11252.

The idea is to refresh full size attributes for the changes you mentioned. I guess FWD should force doLayout() in this case for window GUI widget. Applied to static or visible windows only.

Eugenie Lyzenko wrote:

Hynek Cihlar wrote:

Code review 3548a revision 11251.

The changes are good. But note that the value of the FULL-* attribute changes when the window layout changes. For example when a menubar is made visible or hidden.

Task branch 3548a has been updated for review to revision 11252.

The idea is to refresh full size attributes for the changes you mentioned. I guess FWD should force doLayout() in this case for window GUI widget. Applied to static or visible windows only.

Code review 3548a revision 11252.

The code changes are OK except the !config().dynamic in WindowGuiImpl.doLayout(). This makes the behavior of the FULL- attributes different for static (default) and dynamic windows. Consider the case when the window layout is changed (for example menu-bar assigned) while the window is not visible.

Hynek Cihlar wrote:

Code review 3548a revision 11252.

The code changes are OK except the !config().dynamic in WindowGuiImpl.doLayout(). This makes the behavior of the FULL- attributes different for static (default) and dynamic windows.

Static and dynamic windows are really handling differently. Dynamic windows do not have FULL-* attributes defined until becoming visible.

Consider the case when the window layout is changed (for example menu-bar assigned) while the window is not visible.

In this case static window will update FULL-* attributes, while dynamic - not.

What is wrong here?

Eugenie Lyzenko wrote:

Consider the case when the window layout is changed (for example menu-bar assigned) while the window is not visible.

In this case static window will update FULL-* attributes, while dynamic - not.

What is wrong here?

The test case is as follows. Show a window, hide it, assign menu-bar, read the FULL- attributes (this is where the behavior differs in 3548a; in the native app FULL- attributes report the same values for default-window and dynamic windows), show the window.

Hynek Cihlar wrote:

The test case is as follows. Show a window, hide it, assign menu-bar, read the FULL- attributes (this is where the behavior differs in 3548a; in the native app FULL- attributes report the same values for default-window and dynamic windows), show the window.

Task branch 3548a has been updated for review to revision 11253.

OK. Must be fixed with this update.

Code review 3548a revision 11253.

The changes are OK. I don't register any more open points for the branch.

What GUI testing is needed to confirm this is safe for trunk? Is it enough to test the AW and Hotel usage cases?

Greg Shah wrote:

What GUI testing is needed to confirm this is safe for trunk? Is it enough to test the AW and Hotel usage cases?

I think it is enough. The standalone test and AW is working OK.

Have you already tested Hotel GUI?

Greg Shah wrote:

Have you already tested Hotel GUI?

In progress now. Need to check one option comparing with trunk. Up to 30 min. more I guess.

Not found the regressions in hotel GUI.

But found issue in trunk for hotel GUI. When window is restoring from maximized state by restore title bar button the window size is not changing but location is changed to become negative so the top-left corner of the window is moving outside the visible area.

Please merge 3548a to trunk.

But found issue in trunk for hotel GUI. When window is restoring from maximized state by restore title bar button the window size is not changing but location is changed to become negative so the top-left corner of the window is moving outside the visible area.

Please create a new task for this and link it here.

Branch 3548a was merged to trunk as revno 11248 then it was archived.

Did you test Hotel GUI in both Swing and Web?

Greg Shah wrote:

Did you test Hotel GUI in both Swing and Web?

Yes. The Swing difference is in new issue that found. Swing window (size and location) is not changing comparing to maximized state.