Project

General

Profile

Bug #5809

Setting sizing attributes for WINDOW and FRAME widgets issues

Added by Vladimir Tsichevski over 2 years ago. Updated over 2 years ago.

Status:
WIP
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

20%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

frame_generator.xml.diff Magnifier (1.28 KB) Vladimir Tsichevski, 11/10/2021 02:04 PM

static-frame-virt-width.p Magnifier (1.7 KB) Vladimir Tsichevski, 11/10/2021 03:47 PM

static-frame-set-height.p Magnifier (12.9 KB) Vladimir Tsichevski, 11/16/2021 11:03 AM

5809-issue7.png (29.6 KB) Vladimir Tsichevski, 11/16/2021 11:07 AM

History

#1 Updated by Vladimir Tsichevski over 2 years ago

  • Subject changed from Window: setting sizing attributes issues to Setting sizing attributes for WINDOW and FRAME widgets issues

Issue 1.

Setting FRAME VIRTUAL-WIDTH-PIXELS attribute to zero:

in 4gl:

A warning is displayed:

** Attribute WIDTH-PIXELS must be greater than zero on FRAME outerFrame. (4084)

and the following assignments occur:

VIRTUAL-WIDTH-PIXELS = 0
WIDTH-PIXELS = 19

in FWD:
Two warnings are displayed: 
** Attribute WIDTH-PIXELS must be greater than zero on FRAME outerFrame. (4084)
** Attribute WIDTH must be greater than zero on FRAME outerFrame. (4084)

Neither WIDTH-PIXELS nor VIRTUAL-WIDTH-PIXELS attribute is changed.
First mentioned in #5345-71

Issue 2

Assignment window:VIRTUAL-WIDTH-PIXELS = 0

In FWD: code in PaneEntity:setVirtWidthPixelsWorker(int):

      integer w = _getWidthPixels();
      int dw = w.intValue();

      if (width < dw)
      {
         // decreasing below regular size also affects regular size
         setWidthPixels(width);
      }

forces the window pixels width decrease to zero, which in turn causes an error.

In 4gl the check is made if the new virtual width is enough to hold all contained widgets. If yes, then the window virtual width is set to zero, and the window width is decreased to some value. No error is reported.

First mentioned in #5345-74

Issue 3

Setting window:MAX-WIDTH-PIXELS to value lesser than window:VIRTUAL-WIDTH-PIXELS:

  1. in FWD: assigns window:VIRTUAL-WIDTH-PIXELS = window:MAX-WIDTH-PIXELS
  2. in 4gl: does not affect window:VIRTUAL-WIDTH-PIXELS.

The code responsible WindowWidget:

   protected void setMaxWidthPixelsWorker(int width)
   {
      config.maxWidthPixels= width;

      if (width < config.minWidthPixels)
         config.minWidthPixels = width;

      if (width < config.widthPixels)
         config.widthPixels = width;

      if (width < config.virtualWidthPixels)
         config.virtualWidthPixels = width;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   }

was this assignment done intentionally or can be just removed from this code?

First mentioned in #5345-84

#3 Updated by Vladimir Tsichevski over 2 years ago

Issue 4

At the time frame is realized, its VIRTUAL-WIDTH, if unset, should be assigned from its WIDTH. Seems, it is not the case in FWD.

First mentioned in #5345-87

#4 Updated by Vladimir Tsichevski over 2 years ago

Issue 5 (fixed)

Scrollable frame conversion issue. The following frame declaration:

DEFINE FRAME outerFrame 
   WITH
      SIZE-PIXELS 200 BY 800
      SCROLLABLE
      .

Is converted as:

      public void setup(CommonFrame frame)
      {
         frame.setDown(1);
         frame.setWidthPixels(180);
         frame.setHeightPixels(800);
         frame.setScrollable(true);

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

#5 Updated by Vladimir Tsichevski over 2 years ago

Vladimir Tsichevski wrote:

Issue 5

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

Attached is the patch to fix the conversion.

#6 Updated by Vladimir Tsichevski over 2 years ago

Issue 6

In FWD frame virtual width is reset when set equal to frame width. 4gl does not show this behavior.

The offending code is in PaneEntity:

   @Override
   protected void setVirtWidthPixelsWorker(int width)
   {
      integer w = _getWidthPixels();
      int dw = w.intValue();

      if (width < dw)
      {
         // decreasing below regular size also affects regular size
         setWidthPixels(width);
      }

      if (width <= dw)
      ^^^^^^^^^^^^^^^^
      {
         // make the effective virtual size the regular size
         config.virtualWidthPixels = BaseConfig.INV_COORD;
      }
      else
      {
         config.virtualWidthPixels = width;
      }
   }

The test app static-frame-virt-width.p attached.

#7 Updated by Vladimir Tsichevski over 2 years ago

  • Status changed from New to WIP

#8 Updated by Hynek Cihlar over 2 years ago

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

#9 Updated by Vladimir Tsichevski over 2 years ago

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

Good question. It seems, in 4gl, frames are always scrollable just after the declaration, regardless the SCROLLABLE was set or not:

DEFINE FRAME testFrame 
   WITH
      SIZE-PIXELS 200 BY 800
      .
MESSAGE FRAME testFrame:SCROLLABLE. // prints "yes"

This contradicts to the official OpenEdge docs.
So, it is impossible to declare not-scrollable frames.

#10 Updated by Hynek Cihlar over 2 years ago

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

Good question. It seems, in 4gl, frames are always scrollable just after the declaration, regardless the SCROLLABLE was set or not:

[...]

This contradicts to the official OpenEdge docs.
So, it is impossible to declare not-scrollable frames.

Interesting. Please also test if the behavior does really exhibit the scrolling behavior when the SCROLLABLE option is omitted (i.e. whether you can make the virtual size greater than the regular size and scroll bars show up). And also check how the scrollable attribute behaves for dynamic frames.

#11 Updated by Vladimir Tsichevski over 2 years ago

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

Good question. It seems, in 4gl, frames are always scrollable just after the declaration, regardless the SCROLLABLE was set or not:

[...]

This contradicts to the official OpenEdge docs.
So, it is impossible to declare not-scrollable frames.

Interesting. Please also test if the behavior does really exhibit the scrolling behavior when the SCROLLABLE option is omitted (i.e. whether you can make the virtual size greater than the regular size and scroll bars show up). And also check how the scrollable attribute behaves for dynamic frames.

In 4gl:

If SCROLLABLE = FALSE, then VIRTUAL-WIDTH is a read-only attribute, which always returns the frame WIDTH. Attempt to assign the VIRTUAL-WIDTH attribute raises a warning and does nothing. This holds both for static and dynamic frames. This matches the official docs.

For dynamic frames this can be defined in CREATE FRAME declaration using SCROLLABLE = TRUE in the FRAME phrase.
For static frames this cannot be achieved in DEFINE FRAME declaration, and can only be assigned afterwards.

I have not tested this in converted FWD application yet.

#12 Updated by Hynek Cihlar over 2 years ago

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

Good question. It seems, in 4gl, frames are always scrollable just after the declaration, regardless the SCROLLABLE was set or not:

[...]

This contradicts to the official OpenEdge docs.
So, it is impossible to declare not-scrollable frames.

Interesting. Please also test if the behavior does really exhibit the scrolling behavior when the SCROLLABLE option is omitted (i.e. whether you can make the virtual size greater than the regular size and scroll bars show up). And also check how the scrollable attribute behaves for dynamic frames.

In 4gl:

If SCROLLABLE = FALSE, then VIRTUAL-WIDTH is a read-only attribute, which always returns the frame WIDTH.

With one caveat. When the virtual size is already greater than the regular size, and you set scrollable to false, the virtual size is kept greater than regular size.

#13 Updated by Vladimir Tsichevski over 2 years ago

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.
Hynek, am I correct here?

How does OpenEdge/4GL behave here? Does it treat the size assignments as if scrollable set?

Good question. It seems, in 4gl, frames are always scrollable just after the declaration, regardless the SCROLLABLE was set or not:

[...]

This contradicts to the official OpenEdge docs.
So, it is impossible to declare not-scrollable frames.

Interesting. Please also test if the behavior does really exhibit the scrolling behavior when the SCROLLABLE option is omitted (i.e. whether you can make the virtual size greater than the regular size and scroll bars show up). And also check how the scrollable attribute behaves for dynamic frames.

In 4gl:

If SCROLLABLE = FALSE, then VIRTUAL-WIDTH is a read-only attribute, which always returns the frame WIDTH.

With one caveat. When the virtual size is already greater than the regular size, and you set scrollable to false, the virtual size is kept greater than regular size.

Is this desired behavior or a thing to fix?

#14 Updated by Hynek Cihlar over 2 years ago

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

With one caveat. When the virtual size is already greater than the regular size, and you set scrollable to false, the virtual size is kept greater than regular size.

Is this desired behavior or a thing to fix?

This is a desired behavior.

#15 Updated by Vladimir Tsichevski over 2 years ago

Vladimir Tsichevski wrote:

Issue 5

Scrollable frame conversion issue. The following frame declaration:
[...]

Is converted as:

[...]

The problem here is that at the moment setWidthPixels is called, the frame is not scrollable yet, and this affect the method logic.

So, the call to setScrollable should be placed before the calls to sizing methods.

Fixed in 3821c rev. 13160.

#16 Updated by Vladimir Tsichevski over 2 years ago

  • % Done changed from 10 to 20

#17 Updated by Greg Shah over 2 years ago

Code Review Task Branch 3821c Revision 13160

Please put a comment above the setScrollable lines that "scrollable must be emitted before emitting width or height setters". Since you have found this is a dependency, we at least need to make the dependency obvious to future editors of the code.

#18 Updated by Vladimir Tsichevski over 2 years ago

Greg Shah wrote:

Code Review Task Branch 3821c Revision 13160

Please put a comment above the setScrollable lines that "scrollable must be emitted before emitting width or height setters". Since you have found this is a dependency, we at least need to make the dependency obvious to future editors of the code.

Done in rev. 13164.

#19 Updated by Vladimir Tsichevski over 2 years ago

Issue 7

Automatic frame placement along the Y axis at the client side works incorrectly.

In the example static-frame-set-height.p attached, in FWD the outerFrame is automatically placed at 20 pixels along the Y axis, so outerFrame:Y returns 20 instead of 0.

In 4gl this does not happen.
See how this example looks in 4gl and FWD:

Also available in: Atom PDF