FWD » Core Development » User Interface

As far as I can tell, the client correctly draws the vertical scrollbar. The problem is that it has an incorrect position which comes from the server.

Spent some time in ThinClient.pushWidgetAttr() and observed that when making the window bigger, the width value of the frame is sent correctly from the server and updated accordingly on the client. If I make the window smaller, this value seems to not change, so the problem may not be related to the actual drawing, but rather with the attributes which are sent to the client.

Razvan-Nicolae Chichirau wrote:

As far as I can tell, the client correctly draws the vertical scrollbar. The problem is that it has an incorrect position which comes from the server.

Spent some time in ThinClient.pushWidgetAttr() and observed that when making the window bigger, the width value of the frame is sent correctly from the server and updated accordingly on the client. If I make the window smaller, this value seems to not change, so the problem may not be related to the actual drawing, but rather with the attributes which are sent to the client.

That would explain why limiting the width assignment fixed the issue in the past. I think the +20 width is still being applied when resizing to the left.

Also, to be more clear about the previous fix for this that was in trunk, this was the patch:

=== modified file 'src/com/goldencode/p2j/ui/FrameWidget.java'
--- old/src/com/goldencode/p2j/ui/FrameWidget.java    2025-09-30 10:41:57 +0000
+++ new/src/com/goldencode/p2j/ui/FrameWidget.java    2025-11-19 08:44:10 +0000
@@ -2988,7 +2988,7 @@
                final PaneEntity paneEntity = (PaneEntity) f;
                final int virtualWidth = paneEntity.getVirtWidthPixels().intValue();
                final int ancestorWidth = paneEntity.getWidthPixels().intValue();
-               int maxWidth = virtualWidth - x;
+               int maxWidth = ancestorWidth - x;

                if (virtualWidth > 0 && restrictedWidth > maxWidth)
                {

If this width assignment frame fr_parent:VIRTUAL-WIDTH-PIXELS = current-window:width-pixels. takes place after the resize, that explains the bug entirely and why the workaround works.

Discovered why the server pushes wrong values to the client. So when making the window bigger, the WIDTH-CHARS is not set because of this code in PaneEntity.setVirtWidthCharsWorker():

if (width < _getWidthChars().doubleValue())
{
   // decreasing below regular size also affects regular size
   setWidthChars(width);
}

When making the window smaller, WIDTH-CHARS is set due to the same code. This will end up calling FrameWidget.setWidthImpl() -> config.widthPixels = restrictedWidth;, where restrictedWidth has the newly updated value. After this assignment, SyncCoordinatesAspect.afterSetWidthPixels() kicks in:

public void afterSetWidthPixels(BaseConfig cfg)
{
   if (isSuspended())
      return;

   WorkArea wa = contextData.get();

   cfg.widthChars = wa.cc.columnFromPixels(cfg.widthPixels);
}

, where isSuspended() returns true, preventing the update of cfg.widthChars. This is important because widthChars (and not widthPixels) is used on the client when setting the frame dimensions.

I've tested by manually making isSuspended() return false while executing frame fr_parent:VIRTUAL-WIDTH-PIXELS = current-window:width-pixels. and the vertical scrollbar is set now in the right position.

Well I didn't think of checking aspect assignments so great job, but adding unexpected behaviors in aspects seems like an awful idea exactly due to scenarios like this. We expect aspects to do a basic assignment and no more.

Once the bug is solved I would document this somewhere in the width assignment functions.

The suspend part is intentional because BaseEntity.setSizePixels() is defined as such:

@NoSyncCoordinates
protected void setSizePixels(Integer value, SizeAttribute attr)

This triggers SyncCoordinatesAspect.suspend() on method entry and SyncCoordinatesAspect.resume() on method exit. I think this was implemented to avoid side-effects while modifying any dimension-related attributes.

Razvan-Nicolae Chichirau wrote:

I think this was implemented to avoid side-effects while modifying any dimension-related attributes.

Correct.

Code review 10423a.

Instead of widthFromNative use columnFromPixels. The value truly represents pixels so in ChUI the conversion wouldn't work correct.

Should the assignment be done only when SCA.isSuspended()?

Also should the same modification be done for setHeightImpl?

Hynek Cihlar wrote:

Code review 10423a.

Instead of widthFromNative use columnFromPixels. The value truly represents pixels so in ChUI the conversion wouldn't work correct.

Should the assignment be done only when SCA.isSuspended()?

Also should the same modification be done for setHeightImpl?

Right, it should also hold for setHeightImpl. I've tested with the following procedure: ShowHide

define frame fr_main.
define frame fr_parent.
frame fr_parent:frame = frame fr_main:handle.

current-window:width-pixels = 300.
current-window:height-pixels = 200.

frame fr_main:scrollable = true.
frame fr_main:width-pixels = 300.
frame fr_main:height-pixels = 200.
frame fr_main:bgcolor = 7.

frame fr_parent:scrollable = true.
frame fr_parent:width-pixels = 300.
frame fr_parent:height-pixels = 100.
frame fr_parent:virtual-width-pixels = 400.
frame fr_parent:virtual-height-pixels = 150.
frame fr_parent:BGCOLOR = 5.
on window-resized of current-window do:
    frame fr_main:height-pixels = current-window:height-pixels.
    frame fr_parent:height-pixels = current-window:height-pixels + 20.
    frame fr_main:virtual-height-pixels = current-window:height-pixels.
    frame fr_parent:VIRTUAL-height-PIXELS = current-window:height-pixels.
end.

enable all with frame fr_main.
wait-for go of frame fr_parent.

Please check 10423a/rev. 16279.

Hynek Cihlar wrote:

Should the assignment be done only when SCA.isSuspended()?

Otherwise the assignment triggers the aspect, I don't think this is desired.

Hynek Cihlar wrote:

Hynek Cihlar wrote:

Should the assignment be done only when SCA.isSuspended()?

Otherwise the assignment triggers the aspect, I don't think this is desired.

Razvan, please reply to "Should the assignment be done only when SCA.isSuspended()?".

If we would remove the if statement, heightChars would be basically updated twice: once when setting heightPixels by SCA.afterSetHeightPixels(), and once from the explicit assignment.

So, the answer is yes. The assignment should be done only when SCA.isSuspended() to avoid setting the config field twice.

• ChUI regression tests
• tests from testcases projects related to HEIGHT-CHARS, HEIGHT-PIXELS, WIDTH-CHARS and WIDTH-PIXELS
• smoke-tests for Hotel GUI + 2 other customer apps
• unit-tests from a customer
• isolated testcases, such as #10423-1

If this is enough, we should merge 10423a.

Hynek,

side question: What exactly is Aspect4J used for in the FWD runtime?

IMO this makes development, debugging and maintenance harder:

• FWD building takes a lot of time, incremental building is not available
• the FWD build scenario cannot be reliable reproduced in Eclipse
• debugging stepping is often broken

What would it realistically cost to move away from byte-code instrumentation / Aspect4J completely?
Any internal docs / old tickets discussing alternatives to Aspect4J weaving?

Vladimir Tsichevski wrote:

Hynek,

side question: What exactly is Aspect4J used for in the FWD runtime?

IMO this makes development, debugging and maintenance harder:

Agree. But we are so deep in it that moving away from it would not be an easy task. Search for all the classes *Aspect in the project, you will see what I mean.

• FWD building takes a lot of time, incremental building is not available
• the FWD build scenario cannot be reliable reproduced in Eclipse
• debugging stepping is often broken

For development it helps to switch to runtime time weaving.