Clarion 11: Option group bug?

,
1

Hi all,

in Clarion 11 we noticed the following option group malfunction: if the variable that the option group represents is of type STRING and its value does not match any option in the group, the first option (in the order in which it is declared) is selected. In Clarion 9 in this situation, no option was selected. In Clarion 11 only when the variable is empty nothing is selected.

It seems that if the variable is of the LONG type, the group works fine.

Have any of you noticed a similar problem? Any ideas for a solution? The problem can affect dozens of windows in our system :frowning:

Regards,
Andrzej

2

Have you got an example?

3

Demo app: radio.zip (648,7 KB)

Enter the value you want and press the button to refresh the OPTION.
Radios have values: ‘A’, ‘B’ and ‘C’. The initial value of the underlying variable is ‘Z’ and the OPTION shows the ‘B’ marked as it is the first RADIO declared in the GROUP.

4

Why is this an EXE and not code? I don’t wish to run it.

5

Here is the app: radio-app.zip (19,7 KB)

6

Weird. I can confirm that it behaved differently in C9. In C10 and 11, it sets the value to the first radio in the definition (which is “B”).

I can see how depending on this could cause some headaches and change the data in undesirable ways and I haven’t yet thought of an elegant way to work around the new behavior.

7

The only workarounds I can think of (barring a fix to Clarion, that is) are things that I very much dislike.

Maybe the simplest way could be switching to a listbox? It sucks, but not as much as other solutions I can think of :slight_smile:

Window               WINDOW('Option bug demo'),AT(,,256,153),FONT('Segoe UI',9),RESIZE,GRAY,SYSTEM
                       OPTION('testString'),AT(17,9,76,62),USE(testString),BOXED
                         RADIO(' value ''B'''),AT(29,37),USE(?OPTION1:RADIO2),VALUE('B')
                         RADIO(' value ''A'''),AT(29,23),USE(?OPTION1:RADIO1),VALUE('A')
                         RADIO(' value ''C'''),AT(29,51),USE(?OPTION1:RADIO3),VALUE('C')
                       END
                       LIST,AT(107,10,93,69),USE(testString,,?TestString:3),FROM('Value A|#A|Value B|#B|Value C|#C')
                       BUTTON('Display'),AT(21,121,58,20),USE(?Btn:Display)
                       PROMPT('testString:'),AT(18,81),USE(?testString:Prompt)
                       ENTRY(@s20),AT(18,94,60,10),USE(testString,,?testString:2)
                     END
8

I suppose you could write your own selection logic
For an Option, find all Radios with the matching PROP:Parent
then look at their PROP:Value’s
If there is no match, then clear the USE variable (in this case TestString)

My general approach is have my own shared logic on every window
If you’re using ABC, you can simply derive the WindowManager and call into this code.

9

For an Option, find all Radios with the matching PROP:Parent
then look at their PROP:Value’s
If there is no match, then clear the USE variable (in this case TestString)

I chose exactly the same solution.

In most of our cases the group of options appear on user defined windows, that are created dynamically in our system at runtime. There will be no problem, as we need to implement the woraround in one place only - in our window interpreter procedure.
The situation is worse with dozens of standard, statically declared windows, where we use these controls. Probably the problem affects only a few of them. The easiest way would be to build the woraround into the WindowManager. Then we will not have to identify the individual affected procedures.

Thank you guys for your time, for confirming the bug and for ideas!

Regards,
Andrzej

1 Like