Post by mmseng on Jan 11, 2019 4:25:40 GMT
EDIT: Solved. TL;DR: The value of the TS variable which a ChoiceInput controls, if it has an existing value, takes precedence over the value of the ChoiceInput's "Default" attribute.
I was trying to set the Default attribute value to something different that the value that the ChoiceInput was using, due to having already set the value of the TS variable ealier in my TS.
-------------------
Hi, I'm using v2.11.0.3 and am having an issue with a ChoiceInput where the "Default" attribute is not being respected. I use this to allow for selection of OS. Here is the relevant code:
The result is a dropdown that looks like this (arrow on selected option):
Previously my code looked like this:
which resulted in a dropdown like this:
Because of a former related bug I saw (in this changelog for v2.10.0.0), I tried making the Choice "Option" and "Value" values match, like so:
But that fixed neither the default selection nor the order.
It seems as though the Choices are just being ordered in alphabetic order, based on either the "Option" or "Value" values (where "10" comes before "7" and "1803" comes before "1809"), and the default selected choice at runtime is just the first option in the list. I have no idea whether my previous iteration was unaffected by this, or if it was also bugged and was just a "happy" coincidence that it rendered the way I intended it to. So I seem to have no way to fix this (short of renaming my values, but obviously I rely on those values for my logic elsewhere).
P.S. The ChoiceInput example in the documentation does not seem to use a Default value. And the code in this example provides the Choices in alphabetical order, so obviously they show up that way in the relevant screenshot. I haven't tried using the ChoiceList item yet. I might try that because the example for it seems to at least respect the order of items specified. Although... now that I look at it closer, it doesn't seem to allow for Values to be different from Options, it only seems to have items for Option (olist) and AlternateValues (alist), but not for Values (no vlist)... hmm.
Can anyone replicate this, or help me out?
Thanks,
== Matt
I was trying to set the Default attribute value to something different that the value that the ChoiceInput was using, due to having already set the value of the TS variable ealier in my TS.
-------------------
Hi, I'm using v2.11.0.3 and am having an issue with a ChoiceInput where the "Default" attribute is not being respected. I use this to allow for selection of OS. Here is the relevant code:
<ChoiceInput Variable="my_OS" Question="Select OS" Required="True" Default="Win10x64-1809">
<Choice Option="Windows 10 1809 (x64)" Value="Win10x64-1809" />
<Choice Option="Windows 10 1803 (x64)" Value="Win10x64-1803" />
<Choice Option="Windows 7 (x64)" Value="Win7x64" />
</ChoiceInput>The result is a dropdown that looks like this (arrow on selected option):
Windows 10 1803 (x64) <---
Windows 10 1809 (x64)
Windows 7 (x64)
Previously my code looked like this:
<ChoiceInput Variable="my_OS" Question="Select OS" Required="True" Default="Win10x64-1803">
<Choice Option="Windows 10 1803 (x64)" Value="Win10x64-1803" />
<Choice Option="Windows 7 (x64)" Value="Win7x64" />
</ChoiceInput>which resulted in a dropdown like this:
Windows 10 1803 (x64) <---
Windows 7 (x64)
Because of a former related bug I saw (in this changelog for v2.10.0.0), I tried making the Choice "Option" and "Value" values match, like so:
<ChoiceInput Variable="my_OS" Question="Select OS" Required="True" Default="Win10x64-1809">
<Choice Option="Win10x64-1809" Value="Win10x64-1809" />
<Choice Option="Win10x64-1803" Value="Win10x64-1803" />
<Choice Option="Win7x64" Value="Win7x64" />
</ChoiceInput>But that fixed neither the default selection nor the order.
It seems as though the Choices are just being ordered in alphabetic order, based on either the "Option" or "Value" values (where "10" comes before "7" and "1803" comes before "1809"), and the default selected choice at runtime is just the first option in the list. I have no idea whether my previous iteration was unaffected by this, or if it was also bugged and was just a "happy" coincidence that it rendered the way I intended it to. So I seem to have no way to fix this (short of renaming my values, but obviously I rely on those values for my logic elsewhere).
P.S. The ChoiceInput example in the documentation does not seem to use a Default value. And the code in this example provides the Choices in alphabetical order, so obviously they show up that way in the relevant screenshot. I haven't tried using the ChoiceList item yet. I might try that because the example for it seems to at least respect the order of items specified. Although... now that I look at it closer, it doesn't seem to allow for Values to be different from Options, it only seems to have items for Option (olist) and AlternateValues (alist), but not for Values (no vlist)... hmm.
Can anyone replicate this, or help me out?
Thanks,
== Matt
