For a better compatibility with Lua tables the index of the parameter table should start with 1. Zero is possible, but not common. See also http://chdk.setepontos.com/index.php?topic=2929.msg119764#msg119764
msl
That raises an interesting conflict because the C code is 0 based for the parameter values.
If I change the values table to be 1 based then the selected value passed to the script won't match the label index in the table.
In the script code, you would have to access the label using 'test_table[test_table.value+1]'.
It's a simple enough change if everyone agrees that parameter table should be 1 based.
Phil.
To complicated this, when you use @values the returned selected value is 0 based.
That's what we're discussing - the parameter value passed to the script has always been 0 based from the C code.
#x=0 "Param X" {a b c}
The menu options shown to the user are 'a', 'b' and 'c'; but in the script the values for the variable 'x' are 0, 1 and 2.
The addition of the 'table' option passes the parameter as a table as well as a value.
#x=0 "Param X" {a b c} table
In the current version, the variable 'x' now has:
x[0] = "a"
x[1] = "b"
x[2] = "c"
x.value = index of selected value (0, 1 or 2)
The change suggested by msl and rudi is to have:
x[1] = "a"
x[2] = "b"
x[3] = "c"
x.value = index of selected value (0, 1 or 2)
Edit:One option would be to make everything 1 based if the 'table' option is added to the parameter definition.
E.G.
#x=1 "Param X" {a b c} table
In this case the initial value of 1 above selects the first element (a), the returned table is 1 based, and the selected value will be 1, 2 or 3.
Without the 'table' option the parameter value for 'x' would still be 0, 1 or 2 (for compatibility with existing scripts).
Edit2:Reyalp also had a good suggestion on IRC.
If the 'table' option is used then the we could have 'x.value' be the label of the selected option ('a', 'b' or 'c'), and x.index be the table index (1, 2 or 3).
Phil.
