FWD » Core Development » User Interface

For the web client an application window can be squeezed but can't be resized to widen its width and height.

I tested ./demo/simple_windows.p with the web client. WindowGuiImpl on afterConfigUpdate(WindowConfig beforeUpdate)

      if (beforeUpdate.minHeightPixels != config.minHeightPixels ||
          beforeUpdate.minWidthPixels  != config.minWidthPixels  ||
          beforeUpdate.maxHeightPixels != config.maxHeightPixels ||
          beforeUpdate.maxWidthPixels  != config.maxWidthPixels  ||
          beforeUpdate.resize != config.resize)
      {
         gd.selectWindow(wid);
         gd.setResizeableWindow(config.resize, 
                                config.minWidthPixels, 
                                config.minHeightPixels, 
                                config.maxWidthPixels, 
                                config.maxHeightPixels);
         gd.releaseWindow();
      }

SET_RESIZEABLE_WINDOW: id=1 minw=0 minh=0 maxw=400 maxh=462
SET_RESIZEABLE_WINDOW: id=1 minw=50 minh=0 maxw=400 maxh=462
SET_RESIZEABLE_WINDOW: id=1 minw=50 minh=210 maxw=400 maxh=462
SET_RESIZEABLE_WINDOW: id=23 minw=50 minh=0 maxw=0 maxh=0
SET_RESIZEABLE_WINDOW: id=23 minw=50 minh=210 maxw=0 maxh=0

Committed revision 11008/11009 fixed p2j.logger.log() and history entries.

Greg, could you help? The Swing client doesn't implement setResizeableWindow, but the Web client uses it. The provided values look strange and are less than actual width and height. What do you advise to check?

I think you need to set breakpoints in WindowWidget.setMaxWidthPixelsWorker() and WindowWidget.updateMinMaxSize(), which is where the max*Pixels gets assigned.

Hynek: Any other thoughts?

Greg Shah wrote:

I think you need to set breakpoints in WindowWidget.setMaxWidthPixelsWorker() and WindowWidget.updateMinMaxSize(), which is where the max*Pixels gets assigned.

Hynek: Any other thoughts?

Sergey, you may also set brakepoints in SyncCoordinatesAspect.afterSetMax* methods, make sure you debug both the server and the client.

Hynek Cihlar wrote:

Greg Shah wrote:

I think you need to set breakpoints in WindowWidget.setMaxWidthPixelsWorker() and WindowWidget.updateMinMaxSize(), which is where the max*Pixels gets assigned.

Hynek: Any other thoughts?

Sergey, you may also set brakepoints in SyncCoordinatesAspect.afterSetMax* methods, make sure you debug both the server and the client.

Greg and Hynek, thank you, but the questions will be more than the answers. Why WindowWidget invokes pushScreenDefinition() only for this update methods:

setMessageAreaFont(int64)
setStatusAreaFont(int64)
setTopOnly(boolean)
setVisible(boolean)

It is clear now because this method BaseEntity<T extends BaseConfig>.setSizePixels(Integer value, SizeAttribute attr) uses setMaxWidthPixelsWorker, setMaxHeightPixelsWorker and sends updates to the client.

I tested ./demo/simple_windos.p. If my understanding is correct, then on the server side the default window configuration is fixed by invoking WindowWidget.public void afterConfigUpdate(WindowConfig beforeUpdate) on LogicTerminal.init() and for the second dynamic window this method isn't invoked on the server side and the dynamic window configuration has invalid marker values that must be replaced by the valid window width and height values. Thus I think that ConfigManager.syncConfigChanges(Runnable) must be called on the server side for each WindowWidget update methods. Now we only push window definitions to the client but doesn't notify the server itself. What do you think my proposal is correct?

What do you think my proposal is correct?

This is really a question for Hynek.

Constantin: did any of your reduction in push definition/sync processing affect this area?

The min/maxWidthChars and min/maxHeightChars logic is unclear. These comments WindowWidget.updateMinMaxSize() are confusing:

      // when max attribute is never set, its value equals to the width/height
      // (it grows and shrinks with the values of width/height).
      // When set however, the max value grows with width/height but doesn't
      // shrink.
      if (config.maxWidthPixels != BaseConfig.INV_COORD && 
          config.maxWidthPixels < config.widthPixels)
      {
         config.maxWidthPixels = config.widthPixels;
      }

      if (config.maxWidthPixels != BaseConfig.INV_COORD &&
          config.maxHeightPixels < config.heightPixels)
      {
         config.maxHeightPixels = config.heightPixels;
      }

Sergey Ivanovskiy wrote:

Hynek Cihlar wrote:

Greg Shah wrote:

I think you need to set breakpoints in WindowWidget.setMaxWidthPixelsWorker() and WindowWidget.updateMinMaxSize(), which is where the max*Pixels gets assigned.

Hynek: Any other thoughts?

Sergey, you may also set brakepoints in SyncCoordinatesAspect.afterSetMax* methods, make sure you debug both the server and the client.

Greg and Hynek, thank you, but the questions will be more than the answers. Why WindowWidget invokes pushScreenDefinition() only for this update methods:
[...]
and for the others update methods it uses LogicalTerminal.pushWindow()

LT.pushScreenDefinition() ends up calling LT.pushWindow() for WindowWidget, check the method's body.

or doesn't send updates to the client. For example these methods setMaxWidthPixelsWorker, setMaxHeightPixelsWorker and updateMinMaxSize() are silent for the client.

These methods themselves do not send updates but the methods that call these methods do. Check where these methods get used.

The default window sends its config from LogicalTerminal.init() and SyncCoordinatesAspect.afterSetMaxWidthPixels(WindowConfig cfg) is invoked, but for an ordinal window it isn't invoked.

Probably because your test doesn't call MAX-WIDTH-PIXELS but MAX-WIDTH-CHARS? Put a break point to SCA.afterSetMaxWidthChars(), too.

Sergey Ivanovskiy wrote:

We can fix the unset maxHeightChars and maxWidthChars on the client side using

The max values for the non-default window are assigned somewhere.

WindowManager.setInitialDimension, but these values aren't updated if heightChars and widthChars are changed by business logic. The conversion code of the considered test (./demo/simple_windows.p) doesn't set width and height directly. minHeightChars and minWidthChars are set only

[...]

The max attributes seem to be zeroed in WindowWidget:

   public void afterConfigUpdate(WindowConfig beforeUpdate)
   {
      super.afterConfigUpdate(beforeUpdate);

      // when window is realized
      if (config.realized && !beforeUpdate.realized)
      {
         ...

         // fix max size
         if (config.maxHeightChars == BaseConfig.INV_COORD)
            config.maxHeightChars = config.heightChars;

         if (config.maxWidthChars == BaseConfig.INV_COORD)
            config.maxWidthChars = config.widthChars;
      }
   }

Hynek Cihlar wrote:

Sergey Ivanovskiy wrote:

We can fix the unset maxHeightChars and maxWidthChars on the client side using

The max values for the non-default window are assigned somewhere.

WindowManager.setInitialDimension, but these values aren't updated if heightChars and widthChars are changed by business logic. The conversion code of the considered test (./demo/simple_windows.p) doesn't set width and height directly. minHeightChars and minWidthChars are set only

[...]

The max attributes seem to be zeroed in WindowWidget:
[...]

This method has been called only for the default window from LogicTerminal.init():

         // LT can be used during server start too (i.e. by MetadataManager.populateDatabase)
         // so ensure we have a proper client session
         ConfigManager mgr = ConfigManager.getInstance();

         if (mgr.getActiveConfig(defaultWindow.config().id) == null)
         {
            // TODO: when the context is reset (in an appserver agent), what happens with the 
            // client-side? do the widgets gets destroyed too, and the window's configuration 
            // reinitialized? (i.e. it needs to be pushed by the client-side again?).

            // register only once
            mgr.addWidgetConfig(defaultWindow.config());

            ConfigSyncManager.markScopeStart();
            try
            {
               // the window was registered, activate the config updates
               client.activateConfigUpdates();
               defaultWindow.config().realized = true;
            }

            finally
            {
               ConfigSyncManager.markScopeEnd();
            }
         }

The condition above is satisfied only for non-default windows and because config.heightChars and config.widthChars are never assigned they contain zero values. Instead of config.heightChars (the value assigned on the server by 4GL code), we should use the actual (effective) window size here.

Do you mean to use the actual(effective) window size for the client side in this method WindowManager.setInitialDimension(...) to fix unset values?

I just checked the web client with demo/simple_windows.p setting max attributes or not and I can resize the windows OK. What are the steps to reproduce this issue?

Hynek Cihlar wrote:

I just checked the web client with demo/simple_windows.p setting max attributes or not and I can resize the windows OK. What are the steps to reproduce this issue?

It is possible to decrease the size for the second dynamic window but it is not possible to restore the size after the window size has been decreased by mouse resizing.

The issue is the max width and height are unset on the server side and on the client side.

Is it true that for you this simple example works properly?

Sergey Ivanovskiy wrote:

Is it true that for you this simple example works properly?

Yes, for me simple_windows.p seems to work correctly on Web client. But there may be some steps I am missing. Pls post your exact steps.

Hynek Cihlar wrote:

Sergey Ivanovskiy wrote:

Is it true that for you this simple example works properly?

Yes, for me simple_windows.p seems to work correctly on Web client. But there may be some steps I am missing. Pls post your exact steps.

Nevermind, I can see the problem now.

Ok, :) but the Swing client could have the same problem if it would implement the resizing bounds. It is not the web client issue. We can work with the Swing client because debugging this client and server pair is simpler than the web client and the server.

To resolve the issue, use ConfigHelper.getMaxWidthPixels() and related methods in the call to GuiDriver.setResizeableWindow().

Hynek Cihlar wrote:

To resolve the issue, use ConfigHelper.getMaxWidthPixels() and related methods in the call to GuiDriver.setResizeableWindow().

Thanks, it will help to fix the values on the client side, but the window config leaves unchanged. Is it correct?

Sergey Ivanovskiy wrote:

Hynek Cihlar wrote:

To resolve the issue, use ConfigHelper.getMaxWidthPixels() and related methods in the call to GuiDriver.setResizeableWindow().

Thanks, it will help to fix the values on the client side, but the window config leaves unchanged. Is it correct?

This is correct, the config value reflects the server-assigned value, but not the effective size.

Sergey Ivanovskiy wrote:

The weak place is that don't know if it is possible that the actual window width can be greater than the maximal width assigned by the business logic.

The actual width/height can be greater than max width/max height if assigned by business logic, but not when resized from user input.

Sergey Ivanovskiy wrote:

Committed revision 11010. Please review.

What branch?

Sorry, the committed rev. 11010 is in 1811u.

Sergey Ivanovskiy wrote:

Sorry, the committed rev. 11010 is in 1811u.

The changes are OK.

Let me just suggest to change Math.max(ConfigHelper.getMaxWidthPixels(wcfg), size.width) (and height) to simple ConfigHelper.getMaxWidthPixels(wcfg). This way we will align to the size-limit logic in WindowLayout.doLayout() and, in case the max values are calculated incorrectly, we will have better chance to get consistent behavior with Swing GUI.

Hynek Cihlar wrote:

Sergey Ivanovskiy wrote:

Sorry, the committed rev. 11010 is in 1811u.

The changes are OK.

Let me just suggest to change Math.max(ConfigHelper.getMaxWidthPixels(wcfg), size.width) (and height) to simple ConfigHelper.getMaxWidthPixels(wcfg). This way we will align to the size-limit logic in WindowLayout.doLayout() and, in case the max values are calculated incorrectly, we will have better chance to get consistent behavior with Swing GUI.

I added this check because the configuration size was less than the actual size. It impacts how these windows are resized. Thus if we don't fix it, then we get that the resizing window can't reach its initial actual size.

Hynek: are you OK with me closing this task?

Greg Shah wrote:

Hynek: are you OK with me closing this task?

No more objections here.