I posted a PTSS on it in Sept with a followup in Oct. Of course, never got an SV response as to status.
I appreciate the efforts of Marko in the AnyScreen newsgroup. However, SV sets themselves up to fail when they ignores and/or try to informally substitute for their own bug reporting system. As I have said in the past, SV long ago banned me from their newsgroups so I am unable to contribute other than through a PTSS.
Thanks for your help. Just tested with VALUE and it is indeed a work around I hopefully can use.
On to testing my other issues that were identified last fall.
PTSS 43103 (and 43102) - actually there was a response from Daniel Pavlic 2020/10/12 as follows…
If you assign values for all radio entries it will work. We will fix non-valued radio entries for the next build.
One of the glaring omissions from the PTSS system is the lack of notification by email of responses that are made or questions that are asked.
Crazy really developers can’t be expected to check back again and again on the off chance.
Recently I posted a OPTION to Drop List convertor here. In 13505 there was no PROP to tell the Option was using the Radio Child Index number. When no VALUE() is specified in code the PROP:Value always returns PROP:Text without the Ampersand. So SV will need to either change PROP:Value or have a new PROP.
I can agree about the lack of email, but the true glaring omission looks to be having the report status remain as Submitted even when SV has read or responded. My habit has always been to quickly look at what the PTSS list shows. Silly me for not checking each one further.
Posted in sv.anyscreen …
The possible issue I see is when there is no VALUE() the PROP:Value returns the Radio PROP:Text without the &Amp. So in my example below Radio 2 PROP:Value returns ‘2’ but Radio 3 returns ‘Three’ for PROP:Value.
That’s the PROP … Complicating further is if the OPTION USE() is a Number (LONG) then it gets the Child Index 1,2,3 but if the USE is a STRING then it gets ‘One’,‘2’,‘Three’.
I guess Marko could have it work two different ways by checking if the PROP:Use IsString(). IMO this must be fixed as it is quite common to have OPTION using the Radio child index so could break a lot of code. Maybe the compiler could help by spotting the USE() is a numeric and adding the VALUE(Index) to the Radio.
lRadio LONG !number gets Radio Index number
lRadio STRING(9) !Alternate gets String Value()
OPTION('Op&tions'),AT(10,26,100,52),USE(lRadio),BOXED
RADIO('O&ne'),AT(20,38),USE(?RADIO:1)
RADIO('&Two'),AT(20,50),USE(?RADIO:2),VALUE('2')
RADIO('T&hree'),AT(20,62),USE(?RADIO:3)
END
For option values that are local to the procedure, I usually just use ChoiceFEQ and do not assign employ a variable in USE (ie USE(?MyOption).
VALUE has always required a string. If I include it on RADIOs, my habit has been to create equates in order to have a meaningful label (ie FirstValue EQUATE(‘1’)). I will never have a RADIO with VALUE(‘1’) or even VALUE(‘A’).
As for AnyScreen, I don’t care what is done as long as I know how to have the same code work both as a desktop app and with AnyScreen.