FWD » Core Development » User Interface

This attribute is available on selection list, combo-box and browse column. Please write use cases to test it, including edge cases like unknown value, empty string, use of a different correct delimiters, use of a wrong delimiter (e.g. comma when DELIMITER is set to something else), empty element in the list, multiple sequential empty elements in the list, whitespace in the list.

I understand the LIST-ITEM-PAIRS and RADIO-BUTTONS attributes are in the scope of this task as well. Is that correct?

Yes, I think you are right. Please test and fix any issues related to those.

Another thing: please test these both as options in a VIEW-AS widget-phrase and as attributes.

1. We need to add support for the DELIMITER attribute

2. DELIMITER attribute value cannot be "unknown", but can be "?"

3. Generally speaking the assignment LIST-ITEMS="a,b,c,d" is equivalent to LIST-ITEM-PAIRS = "a,a,b,b,c,c,d,d".

4a. If the DELIMITER != " " and != "?" then:
- for COMBO-BOX trailing spaces of values are dropped (for labels they are left intact). For SELECTION-LIST spaces are left intact both for values and labels.
- for COMBO-BOX "?" is not allowed as value (a warning 4058 is generated) but "? " is allowed and is converted to "?". A "?" in LIST-ITEMS is silently ignored. For SELECTION-LIST ? is treated as a normal character.
- for COMBO-BOX if label is en empty string "" the selected value is always "unknown".

However if an item is "?" it is ignored for the COMBO-BOX (but not for the SELECTION-LIST), but "? " is included as "?". Items consisting of spaces are shown as "" but for the COMBO-BOX the selected value is "unknown" (for the SELECTION-LIST it is "").

4b. If the DELIMITER is " " or "?" the behavior is essentially the same as above except the special treatment of space and question mark respectively.

5. LIST-ITEMS can be empty or "unknown" (which is the same). In this case the drop-down list can be activated with a single selectable item - "unknown".

6. If LIST-ITEMS is specified as a comma-separated list in the VIEW-AS phrase the interpretation of spaces and the question mark is the same as described in section 3 above. An "?" as value in LIST-ITEM-PAIRS for COMBO-BOX is silently ignored. There is a difference with value "? " for COMBO-BOX depending on how it is set: if it was in a VIEW-AS phrase or via ADD-FIRST/ADD-LAST the selected value is string "?" while if it as assigned to the attribute the selected value is "unknown".

RADIO-BUTTONS attribute for the RADIO-SET widget behaves like LIST-ITEM-PAIRS for the SELECTION-LIST.

Conclusion:
It appears that logic for the attributes in question is pretty complicated. I think that it will take me a day or two to adjust the runtime.

BTW: I've noticed that DELETE operation behaves a little bit different than I found before (it deletes items in a COMBO-BOX by value and emits some strange warning in case when the item to delete is not found). It is possible of course that I was wrong and overlooked something. However it is not likely. Is it possible that the 4DL on lindev01 was patched recently?

The version on lindev01 is 10.2B and has not been changed since it was installed in early 2013. I access it via /usr/progress/oe10.2B/dlc/bin/pro.

As far as I know, it is the only Progress version on that system.

It is common to find results later that can appear to contradict earlier findings. I have seen this myself. I have seen this in the past when I didn't fully understand the code I was writing and I implemented approaches that did not fully explore the feature set. Then later, when I understood better and/or explored further, I found my mistakes. This is easy to do in the 4GL where there is so much undocumented and quirky behavior hidden inside the runtime and/or compiler.

I think that it will take me a day or two to adjust the runtime.

Please go ahead with the necessary improvements.

I've discovered a strange behavior: for the COMBO-BOX and SELECTION-LIST ADD-LAST(..., ?) is rejected but the code

DEFINE VARIABLE u AS CHARACTER NO-UNDO.
u = ?.
cb:ADD-LAST(..., u).

is acceptable.

I understand that there is no way to distinguish between these two cases in Java runtime. Id this is the fact should the UNKNOWN value be accepted or rejected?

Are you saying that the 4GL reacts differently in these two situations?

Unknown literal:

cb:ADD-LAST(..., ?).

lvalue that is set to unknown value:

DEFINE VARIABLE u AS CHARACTER NO-UNDO.
u = ?.
cb:ADD-LAST(..., u).

If so, we CAN detect that at runtime because the unknown literal is emitted as new unknown() which is a special subclass of BaseDataType that is used only as the unknown value literal. In other cases, the variable would be passed in as character or whatever type and isUnknown() would need to be used.

Greg Shah wrote:

Are you saying that the 4GL reacts differently in these two situations?

Yes, it does.

If so, we CAN detect that at runtime because the unknown literal is emitted as new unknown() which is a special subclass of BaseDataType that is used only as the unknown value literal. In other cases, the variable would be passed in as character or whatever type and isUnknown() would need to be used.

Oh, I see. Thanks a lot!

Progress is full of these insane "quirks". In these cases we try to leave careful comments and javadoc to explain that we put these "features" in to match specific quirks in the 4GL. Otherwise future maintainers of such code might easily simplify the code thinking that it was a bug. Please leave behind some clear comments to explain that the 4GL actually differentiates between unknown literal and real types set to unknown.

Greg Shah wrote:

Progress is full of these insane "quirks". In these cases we try to leave careful comments and javadoc to explain that we put these "features" in to match specific quirks in the 4GL. Otherwise future maintainers of such code might easily simplify the code thinking that it was a bug. Please leave behind some clear comments to explain that the 4GL actually differentiates between unknown literal and real types set to unknown.

Got it. I've added the comment for this particular case.

Code Review ias_upd20150225a.zip

1. The update should only contain files that were modified for this task. As far as I can tell, that is just the following:

rules/convert/methods_attributes.rules
rules/include/common-progress.rules
src/com/goldencode/p2j/ui/client/RadioSet.java
src/com/goldencode/p2j/ui/ComboBoxWidget.java
src/com/goldencode/p2j/ui/CommonWidget.java
src/com/goldencode/p2j/ui/ControlSetConfig.java (are these really needed?)
src/com/goldencode/p2j/ui/ControlSetEntity.java
src/com/goldencode/p2j/ui/RadioSetWidget.java (are these really needed?)

2. History entries are needed for RadioSet, ControlSetConfig, RadioSetWidget.

3. Should there be more code to handle non-character data types in truncateValue(BaseDataType)?

4. Please format the javadoc for new methods according to coding standards. See ComboBoxWidget and ControlSetEntity.

5. The ControlSetEntity helper interfaces BiPredicate and ItemsList*Expander need javadoc for their methods.

6. The indentation is out of standard in ControlSetEntity.addFirst(character, BaseDataType) and ControlSetEntity.useListItemPairs().

7. The new delimiter methods of ControlSetEntity have their opening { on the wrong line.

Found at least two bugs.
1. When there are several widgets in a frame the cursor position doesn't change when switching between these widgets.
2. NPE in ThinClient.positionCursor() when switching to the RADIO-SET for the first time (in the previous scenario).

Are these bugs specific to your change or are they already existing in P2J?

Greg Shah wrote:

Are these bugs specific to your change or are they already existing in P2J?

These bugs are not caused by my changes.

OK, please do fix these as part of this task.

Code Review ias_upd20150305a.zip

I'm good with the changes.

After 3 runs the following 2 tests failed (in addition to the expected tc_job_002):

398     tc_job_clock_002     TIMCO TC-JOB-CLOCK-002 testcase.     FAILED     NONE     BACKOUT     Driver 0     180.119     

failure in step 2: 'timeout before the specific screen buffer became available (Mismatched data at line 0, column 0. Expected ' ' (0x0020 at relative Y 0, relative X 0) and found '│' (0x2502 at relative Y 0, relative X 0).)'

400     tc_job_clock_004     TIMCO TC-JOB-CLOCK-004 testcase.     FAILED     NONE     BACKOUT     Driver 0     180.119     

failure in step 2: 'timeout before the specific screen buffer became available (Mismatched data at line 0, column 10. Expected ' ' (0x0020 at relative Y 0, relative X 10) and found 'c' (0x0063 at relative Y 0, relative X 10).)'

These tests failed on different steps. The best results are listed above. Test restarted.

Passed runtime regression testing and checked in as bzr rev 10796.

Code Review ias_upd20150309a.zip

The change is good. Please add a history entry, post the updated 0309b zip and get it regression tested. You can check it in as soon as it passes testing.

What is the status of this? Also, please post the updated zip.

Greg Shah wrote:

What is the status of this? Also, please post the updated zip.

Regression test just passed (it required 3 runs).

setListItems() method fixed.
Has passed conversion regression testing and is committed as bzr rev. 10802.

Constantin,
I agree with your changes. However I've noticed another non-compatibility with 4GL:
With your sample running in 4GL it is acceptable to press 1 and then 2 (but not vise versa) while in Java runtime both are rejected. This looks a little bit strange as in my tests it was different. I'm re-checking now.

The situation looks strange. If one puts assignments in Constantin's sample not within "on" block (just two consecutive assignments) the second one will be rejected. Trying to understand the difference. Any suggestions are highly appreciated.

Well, it seems that the situation is the following:
If LIST-ITEMS is assigned before the frame containing the widget is enabled then one can assign to LIST-ITEM-PAIRS after enabling the frame (but not vise versa).

Shall I start the regression testing right now?

Igor Skornyakov wrote:

Shall I start the regression testing right now?

No, don't put this into testing since Constantin is already doing so with his version. After he checks this in (it is urgently required to fix regressions in some customer code), you can move forward with your fix.

Code Review ias_upd20150310a.zip

I'm fine with the proposed changes, except that the ControlSetConfig.java needs a history entry.

As noted above, please wait until after Constantin's check in before you get this tested.

Greg Shah wrote:

Code Review ias_upd20150310a.zip

I'm fine with the proposed changes, except that the ControlSetConfig.java needs a history entry.

I see. And because there will be a separate commit by Constantin I understand a new history entry for the ControlSetEntity should be added as well.

As noted above, please wait until after Constantin's check in before you get this tested.

OK.

And because there will be a separate commit by Constantin I understand a new history entry for the ControlSetEntity should be added as well.

Correct.

Perhaps it makes sense to integrate these changes with your work in #2522 to reduce the amount of testing cycles?

Greg Shah wrote:

Perhaps it makes sense to integrate these changes with your work in #2522 to reduce the amount of testing cycles?

Great! I like this idea.

Has passed regression testing and is committed as bzr rev. 10811