FWD » Core Development » User Interface

Implement conversion and runtime support for the following:

Attributes

NUM-BUTTONS

Methods

DISABLE
ENABLE

Code Review ias_upd20150312a.zip

I'm fine with the changes.

Constantin: please review.

• ControlSetEntity.pairs - the javadoc for return is not formatted properly.
• ControlSetConfig.pairsSetWhenRealized - the javadoc is the same as for the pairs field
  Actually, I don't understand why you need this field. Can you give an example? As I see:
  1. if the LIST-ITEMS attribute is set for an unrealized widget, this will match the widget's unrealized state; and the pairs() API will always return null until the widget is realized - thus you will be able to set the LIST-ITEM-PAIRS after the widget was configured with LIST-ITEMS! Only after the widget is realized this will no longer match.
  2. if the LIST-ITEMS attribute is set for a realized widget, this will match the widget's realized state; and the pairs() API will forever return null - thus the setListItemPairs() will succeed even if LIST-ITEMS was set first.

Check this case:

def var ch as char view-as combo-box.

form ch with frame f1.

ch:list-items = "1,2,3,4".
ch:list-item-pairs = "a,b,c,d".

Do not limit yourself to testing one attribute at a time, especially as the LIST-ITEMS and LIST-ITEM-PAIRS are dependent on each other; set them once, twice, one after the other, with an unrealized widget, with a realized widget, before and after realizing a widget, and all combinations you can think of.

Constantin Asofiei wrote:

About ias_upd20150312a.zip:

• ControlSetEntity.pairs - the javadoc for return is not formatted properly.
• ControlSetConfig.pairsSetWhenRealized - the javadoc is the same as for the pairs field

Thank you - I will fix it.

Actually, I don't understand why you need this field. Can you give an example? As I see:
1. if the LIST-ITEMS attribute is set for an unrealized widget, this will match the widget's unrealized state; and the pairs() API will always return null until the widget is realized - thus you will be able to set the LIST-ITEM-PAIRS after the widget was configured with LIST-ITEMS! Only after the widget is realized this will no longer match.
2. if the LIST-ITEMS attribute is set for a realized widget, this will match the widget's realized state; and the pairs() API will forever return null - thus the setListItemPairs() will succeed even if LIST-ITEMS was set first.

Check this case:
[...]
The widget is not realized, and the LIST-ITEM-PAIRS is not possible to be set, once LIST-ITEMS was set.

Do not limit yourself to testing one attribute at a time, especially as the LIST-ITEMS and LIST-ITEM-PAIRS are dependent on each other; set them once, twice, one after the other, with an unrealized widget, with a realized widget, before and after realizing a widget, and all combinations you can think of.

This is exactly what I did. Please note that with your initial sample (when assigments where in the "on" block it was possible to set LIST-ITEM-PAIRS after LIST-ITEMS was set. This is the reason for adding pairsSetWhenRealized

Code Review ias_upd20150312b.zip

I'm OK with the changes.

Igor, I'm still trying to understand why the pairsSetWhenRealized flag is needed - please post a simple, minimum test which demonstrates what this wants to solve.

Constantin Asofiei wrote:

Igor, I'm still trying to understand why the pairsSetWhenRealized flag is needed - please post a simple, minimum test which demonstrates what this wants to solve.

Actually I was trying to reproduce the behavior of your tests - the one you submitted initially:

def var ch as char.

form ch view-as combo-box inner-lines 2 label "combo" with frame f1.

on "1" anywhere do:
  ch:list-items in frame f1 = "a,b,c,d,e".
end.

on "2" anywhere do:
  ch:list-item-pairs in frame f1 = "1,a,2,b,3,c,4,d,5,e".
end.

update ch with frame f1.

message ch

where one can press "1" and then "2" (but not vise versa)

and the test you've submitted today (this was what I've tried initially, but haven't re-tested).

Igor, I think the update is safe now. But please rename pairsSetWhenRealized to itemsSetWhenRealized - this flag has nothing to do with the LIST-ITEM-PAIRS attribute, as I understand you just need to track if the last time the items were set the widget was already realized or not.

1. unrealized widget:
   a) set LIST-ITEMS (case I)
   or
   b) LIST-ITEM-PAIRS (case II)
   or
   c) do nothing
2. realize widget then:
   a) set LIST-ITEMS first, LIST-ITEM-PAIRS second (case II)
   or
   b) set LIST-ITEM-PAIRS first, LIST-ITEMS second (case III)
   or
   c) do nothing
3. hide widget and do step 3 cases again

Constantin Asofiei wrote:

Igor, I think the update is safe now. But please rename pairsSetWhenRealized to itemsSetWhenRealized - this flag has nothing to do with the LIST-ITEM-PAIRS attribute, as I understand you just need to track if the last time the items were set the widget was already realized or not.

The name was chosen after the name of the 'pairs' flag. However if you think that it can cause confusion I will change it. Please note however that ADD-FIRST/ADD-LAST/DELETE methods also change items (but not the 'pairs' flag). I think it is a matter of taste.

But before putting it in testing, please do some more tests (if you haven't already covered these cases); use a workflow like this (and combinations):

1. unrealized widget:
   a) set LIST-ITEMS (case I)
   or
   b) LIST-ITEM-PAIRS (case II)
   or
   c) do nothing
2. realize widget then:
   a) set LIST-ITEMS first, LIST-ITEM-PAIRS second (case II)
   or
   b) set LIST-ITEM-PAIRS first, LIST-ITEMS second (case III)
   or
   c) do nothing
3. hide widget and do step 3 cases again

I've tested all of the above except hiding. Now I've added it but have noticed nothing new.
Thank you for your advise!

All regression tests (except tc_job_002) passed. Can I commit mt changes?

Please post the final update here.

Yes, you can check it in.

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