Bug #2165
Updated by Greg Shah over 7 years ago
Consider the following code:
<pre>
...
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.
...
</pre>
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:
<pre>
...
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"));
...
</pre>
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).
<pre>
...
┌─────────────────────── 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> │
└───────────────────────────────────────────────────────┘
...
</pre>
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.
<pre>
...
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.
...
</pre>
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:
<pre>
...
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"));
...
</pre>
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).
<pre>
...
┌─────────────────────── 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> │
└───────────────────────────────────────────────────────┘
...
</pre>
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.