FWD » Core Development » User Interface

FIXED The code below

define variable num  as integer.
display num with frame f0.
num = num:dcolor.

Does not work in FWD swing (the application window appears and disappears endlessly).

The same code causes no problem in Progress.

The cause of the problem is NPE in the com.goldencode.p2j.ui.BaseEntity.getDColor() method:

   public integer getDColor()
   {
      int color = config.dcolor.color();
      return (color == -1) ? new integer() : new integer(color);
   }

since the config.dcolor field is null.

Changing the method code to the following one cures the problem:

   public integer getDColor()
   {
      Color dcolor = config.dcolor;
      return (dcolor == null)
         ? new integer()
         : new integer(dcolor.color());
   }

Vladimir Tsichevski wrote:

The code below

[...]

Does not work in FWD swing (the application window appears and disappears endlessly).

The same code causes no problem in Progress.

The cause of the problem is NPE in the com.goldencode.p2j.ui.BaseEntity.getDColor() method:

[...]

since the config.dcolor field is null.

Changing the method code to the following one cures the problem:

[...]

Was removing the case color == -1 intentional?

Hynek Cihlar wrote:

Was removing the case color == -1 intentional?

No, this was my mistake. Please, restore the handling of the -1 value.

Greg Shah wrote:

Vladimir: Please put the change (including the -1 handling) into branch 4124a.

Also, please check the other color attributes (PFCOLOR, FGCOLOR, BGCOLOR) to ensure they don't have the same problem.

Things to be fixed either:

1. The setDColor(NumberType param) causes explicitly constructed NPE (in param.intValue()), if an "unknown" integer is passed as the method argument:

num:dcolor = ?.

To fix this, the method implementation shall be changed from:

   public void setDColor(NumberType param)
   {
      config.dcolor = new ColorSpec(param.intValue()).convert();
      pushWidgetAttr("dcolor", config.dcolor);
   }

to

   public void setDColor(NumberType param)
   {
      int color = (param == null || param.isUnknown()) ? -1 : param.intValue();
      config.dcolor = new ColorSpec(color).convert();
      pushWidgetAttr("dcolor", config.dcolor);
   }

2. The code:

num:pfcolor = ?.

currently causes the NPE by the same reason:

   public void setPfColor(NumberType param)
   {
      config.pfcolor = new ColorSpec(param.intValue()).convert();
      pushWidgetAttr("pfcolor", config.pfcolor);
   }

shall be probably changed to:

   public void setPfColor(NumberType param)
   {
      int color = (param == null || param.isUnknown()) ? -1 : param.intValue();
      config.pfcolor = new ColorSpec(color).convert();
      pushWidgetAttr("pfcolor", config.pfcolor);
   }

Another implication is that Progress allows neither read nor write the pfcolor with the following message:

**Progress does not support the PFCOLOR attribute for FILL-IN num in this display environment. (4088)

FWD does not display anything similar.

I am not sure what shall I do here.

Vladimir Tsichevski wrote:

FWD does not display anything similar.

I am not sure what shall I do here.

You get this error because the PFCOLOR attribute is supported only in ChUI session while you ran the app in GUI. See the method LogicalTerminal.isChui, this will return true when in ChUI. To display the error, use ErrorManager.recordOrShowError. You can see both methods in action for example in BaseEntity.setXorY().

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

FWD does not display anything similar.

I am not sure what shall I do here.

You get this error because the PFCOLOR attribute is supported only in ChUI session while you ran the app in GUI. See the method LogicalTerminal.isChui, this will return true when in ChUI. To display the error, use ErrorManager.recordOrShowError. You can see both methods in action for example in BaseEntity.setXorY().

I run in GUI mode both FWD (gui_swing) and Progress. I see the message in Progress, and I do not see it in FWD.

So, I need to

1. Check if I am in terminal mode with LogicalTerminal.isChui();
2. If not, refuse both getting and setting attempts with the message above.

Is that correct?

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

FWD does not display anything similar.

I am not sure what shall I do here.

You get this error because the PFCOLOR attribute is supported only in ChUI session while you ran the app in GUI. See the method LogicalTerminal.isChui, this will return true when in ChUI. To display the error, use ErrorManager.recordOrShowError. You can see both methods in action for example in BaseEntity.setXorY().

I run in GUI mode both FWD (gui_swing) and Progress. I see the message in Progress, and I do not see it in FWD.

So, I need to

1. Check if I am in terminal mode with LogicalTerminal.isChui();
2. If not, refuse both getting and setting attempts with the message above.

Is that correct?

Correct. Just check the behavior for both attribute read and write in OpenEdge.

Hynek Cihlar wrote:

Correct. Just check the behavior for both attribute read and write in OpenEdge.

The same error message is displayed both for read and write of pfcolor in OpenEdge.

Vladimir Tsichevski wrote:

The same error message is displayed both for read and write of pfcolor in OpenEdge.

Correction: OpenEdge emits the warning on the write only, and it does not prevent either reading or writing operation.

Correction 2: when in GUI, OpenEdge silently does not write the dcolor attribute, and reading the dcolor silently returns undefined value.

So, despite the OpenEdge docs say neither dcolor nor pfcolor are used in GUI mode, the treatment of this attributes differs in OpenEdge.

New observation: OpenEdge refuses to set both fgcolor and bgcolor to any negative value.

In FWD:

num:fgcolor = -1.
num:bgcolor = -1.

both set the corresponding color to undefined.

num:bgcolor = -2.

just sets the bgcolor to -2.

1. In any mode OpenEdge refuses to set any color indices greater than 255 with the following message:

Invalid color index: 256 is greater than the current max value. (4086)

2. In Character mode OpenEdge silently ignores the new color value after checking it for validity for fgcolor and bgcolor.

Exception: In Character mode OpenEdge only does not complain about the invalid color index for bgcolor :(

The Progress vs. FWD operations summarized in the following table:

The message mentioned in the table above are:

1.

Invalid color index: 256 is greater than the current max value. (4086)

2.

Progress does not support the PFCOLOR attribute for the FILL-IN num in this display environment. (4088)

3.

Attribute BGCOLOR must be greater than or equal to 0 in FILL-IN num. (4082)

Note1: the fgcolor and bgcolor behave differently in Character mode.
Note2: 2-byte integers are used to display invalid color indices, so if you try num:dcolor = 65536, the warning will look like:

Invalid color index: 0 is greater than the current max value. (4086)

At the moment I cannot reach 100% compatibility with Progress in that how the dcolor and pfcolor colts are treated, at least, in GUI mode.

The reason is that it seems FWD does not keep the original integer color value for these slots, and tries to convert them to Color objects.

The method Color ColorSpec.convert(ColorSpec cs) in GUI mode looks like the following:

      public Color convert(ColorSpec cs)
      {
         GUIWorkArea wa = locate();
         Color color = null;
         if (cs.colorValue instanceof String)
         {
            ... process color name here
         }

         return color;      

      }

So, anything but Strings, is silently ignored, and the method always return null.

But currently the color setters look like the following (this code is before I changed it a bit, but that does not matter in this case):

   public void setPfColor(NumberType param)
   {
      config.pfcolor = new ColorSpec(param.intValue()).convert();
      pushWidgetAttr("pfcolor", config.pfcolor);
   }

So they always set the config.dcolor and config.pfcolor to null when in GUI mode.

Meanwhile the Progress allows to change these values even when in GUI mode, and the update values can be read back.

Probably we need to make the dcolor and pfcolor handling after than for fgcolor and bgcolor, and always keep the color indices as integers? This is to achieve the full compatibility only, the values themselves are not used by FWD run time.

The change here 11451 or 11452 causes the StackOverflow for endless com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798) calls in a customer application.

Server.log for StackOverflow.

[08/14/2019 02:48:02 MSK] (com.goldencode.p2j.util.TransactionManager:SEVERE) Abnormal end; original error:
java.lang.StackOverflowError
        at java.lang.ThreadLocal.get(ThreadLocal.java:161)
        at com.goldencode.p2j.security.ContextLocal.get(ContextLocal.java:469)
        at com.goldencode.p2j.security.ContextLocal.get(ContextLocal.java:430)
        at com.goldencode.p2j.main.StandardServer.getClientParameters(StandardServer.java:731)
        at com.goldencode.p2j.ui.LogicalTerminal.isChui(LogicalTerminal.java:8870)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:796)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
        at com.goldencode.p2j.ui.BaseEntity.setBgColor(BaseEntity.java:798)
...

The following code in BaseEntity causes endless recursive loop in GUI mode:

   public void setBgColor(integer bgcolor)
   {
      if (bgcolor == null || bgcolor.isUnknown())
      {
         if (!LogicalTerminal.isChui())
         {
            setBgColor(new integer()); <---- endless call to myself
         }

         return;
      }
...
   public void setFgColor(integer fgcolor)
   {
      if (fgcolor == null || fgcolor.isUnknown())
      {
         setFgColor(new integer()); <---- endless call to myself
         return;
      }
...
   public void setDColor(NumberType param)
   {
      if(param == null || param.isUnknown())
      {
         setDColor(new integer()); <---- endless call to myself
         return;
      }
...

If you will not able to commit the change in 30 min I'll make the fix and commit. Because it is stopper for me now.

Task branch 4124a has been updated for review to revision 11453.

This is the fix for StackOverflow from endless recursion and another NPE in FillIn painting code.

Note the UNKNOWN(?) Progress value does not mean the object is NULL in FWD world.

Eugenie Lyzenko wrote:

Task branch 4124a has been updated for review to revision 11453.

Ok, thank, you were first.

Note the UNKNOWN(?) Progress value does not mean the object is NULL in FWD world.

I know this, thanks.

Wow, this issue is already 6 years old! Which branch should be reviewed? 4124a doesn't exist.

Hynek Cihlar wrote:

Wow, this issue is already 6 years old! Which branch should be reviewed? 4124a doesn't exist.

This was merged into trunk forever ago:

revno: 11329 [merge]
committer: Constantin Asofiei <ca@goldencode.com>
branch nick: trunk
timestamp: Tue 2019-09-24 03:02:32 -0400
message:
  This branch is a collection of many fixes, some related to UI, others to conversion, core logic or persistence fixes.  Main task was #4121; a highlight is bellow:
  - Implementation for the client-side web requests. #4124
  - Added dataset support. #3809
  - Client-principal fixes. #3810
  - Completed cross-messaging support via global publish/subscribe. Refs #3253
  - Getting/setting dcolor, pfcolor, fgcolor and bgcolor now mostly matches that in Progress (see #4221 for details).
  - Added Java open client compatibility; fixed appserver calls for dataset and table arguments. #4140
  - Fixing cases of BY-REFERENCE/BIND with DATASET, DATASET-HANDLE, TABLE and TABLE-HANDLE arguments (refs #3816).
  - Implemented stream name server-client serialization. #3751
  - Fixed a ChangeBroker registered listener leak (refs #4121)
  - Fixed lookup of resources for metadata tables; fixed infinite loop in AdaptiveFind; refs #4121
  - Compare operators using DATETIME-TZ values as operators are converted to Java UDFs; the DATETIME-TZ is processed in the argument as a ISO date, formatted to string. Refs #2156
  - Runtime support for legacy WebHandler (refs #3855)
  - OCX conversion fixes

So, I think this task can be closed.

Why is the task set to 80%?