Project

General

Profile

Bug #2165

Handling "color skip" phrase produces incorrect color attribute selection

Added by Eugenie Lyzenko over 10 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
08/19/2013
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

color-4gl-linux.jpg - "color skip" 4GL Linux (184 KB) Eugenie Lyzenko, 08/19/2013 12:40 PM

color-4gl-windows.jpg - "color skip" 4GL Windows (77.8 KB) Eugenie Lyzenko, 08/19/2013 12:40 PM

color-p2j-linux.jpg - "color skip" P2J Linux (196 KB) Eugenie Lyzenko, 08/19/2013 12:40 PM

color-p2j-windows.jpg - "color skip" P2J Windows (123 KB) Eugenie Lyzenko, 08/19/2013 12:40 PM

History

#1 Updated by Greg Shah over 7 years ago

  • Description updated (diff)

Consider the following code:

...
message color skip
   "This is the color attribute text. Depending on the " skip(0)
   "current console OS color settings it can be colored" skip(0)
   "or not. The buttons below should have one letter   " skip(0)
   "underligned and button <No> should have reverse    " skip(0)
   "color attribute meaning the current selection. Hit " skip(0)
   "arrow keys to change the current selection, ENTER  " skip(0)
   "to select curent button.                           " skip(0)
    view-as alert-box warning buttons yes-no-cancel update res as log.
...

This is potentially wrong 4GL clause (standalone color phrase) but it is considered as correct in 4GL and produces the alert box below(like following skip has been ignored). To see: color-4gl-linux.jpg and color-4gl-windows.jpg
The P2J converts this as:
...
            messageBox(new Object[]
            {
               "This is the color attribute text. Depending on the ",
               new SkipEntity(0),
               "current console OS color settings it can be colored",
               new SkipEntity(0),
               "or not. The buttons below should have one letter   ",
               new SkipEntity(0),
               "underligned and button <No> should have reverse    ",
               new SkipEntity(0),
               "color attribute meaning the current selection. Hit ",
               new SkipEntity(0),
               "arrow keys to change the current selection, ENTER  ",
               new SkipEntity(0),
               "to select curent button.                           ",
               new SkipEntity(0)
            }, false, new AccessorWrapper(res), ALERT_WARNING, BTN_YES_NO_CANCEL, null, new ColorSpec("skip"));
...

Note the "color skip" also ignore the "skip" word considering the "skip" as color name. This is wrong and the resulting alert box becomes in wrong color. We can not detect this in regression testing because the text attributes are not comparing. The both Linux and Windows P2J implementations show the same results: color-p2j-linux.jpg and color-p2j-windows.jpg. The correct color to be used in this case finally is ColorSpec(ColorSpec.COLOR_MESSAGES).
...
           ┌─────────────────────── Warning ───────────────────────┐
           │ This is the color attribute text. Depending on the    │
           │ current console OS color settings it can be colored   │
           │ or not. The buttons below should have one letter      │
           │ underligned and button <No> should have reverse       │
           │ color attribute meaning the current selection. Hit    │
           │ arrow keys to change the current selection, ENTER     │
           │ to select curent button.                              │
           │ ───────────────────────────────────────────────────── │
           │                  <Yes> <No> <Cancel>                  │
           └───────────────────────────────────────────────────────┘
...

Another consideration here from Greg's answer for issue discussion:

I think that both of these issues are runtime problems. Even the color skip issue is something that the runtime should handle the same way as the 4GL. The 4GL code in this case is picking a different default match for a "non-sense" color name. We need to do the same. If I recall correctly, we have seen this before and for some reason, matching this behavior caused issues elsewhere. If that is correct, then there are something deeper that is wrong with our implementation which we didn't figure out the first time.

Also available in: Atom PDF