Proposed changes to script parameters

reyalp

14110

Re: Proposed changes to script parameters

« Reply #30 on: 29 / December / 2014, 13:06:37 »

Advertisements

Quote from: philmoz on 28 / December / 2014, 22:17:54

There is also at least one camera where the aperture table in shooting.c includes ND filter simulated values.

In general, I think all (or almost all) the ND only ports do this. It seemed to be the standard when I got involved. The accuracy of these tables across ports is probably suspect, since they don't affect normal CHDK operation much.

Logged

Don't forget what the H stands for.

msl

1280
A720 IS, SX220 HS 1.01a

Re: Proposed changes to script parameters

« Reply #31 on: 10 / January / 2015, 14:51:28 »

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

Logged

CHDK-DE: CHDK-DE links

philmoz

3450

Re: Proposed changes to script parameters

« Reply #32 on: 10 / January / 2015, 16:52:22 »

Quote from: msl on 10 / January / 2015, 14:51:28

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.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

waterwingz

12140

Re: Proposed changes to script parameters

« Reply #33 on: 10 / January / 2015, 17:19:13 »

Quote from: philmoz on 10 / January / 2015, 16:52:22

Quote from: msl on 10 / January / 2015, 14:51:28
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.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Proposed changes to script parameters

« Reply #34 on: 10 / January / 2015, 17:30:44 »

Quote from: waterwingz on 10 / January / 2015, 17:19:13

Quote from: philmoz on 10 / January / 2015, 16:52:22
Quote from: msl on 10 / January / 2015, 14:51:28
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.

Code: [Select]

#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.

Code: [Select]

#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.

Code: [Select]

#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.

« Last Edit: 10 / January / 2015, 18:02:02 by philmoz »

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

philmoz

3450

Re: Proposed changes to script parameters

« Reply #35 on: 10 / January / 2015, 23:44:49 »

Here's a patch that implements the changes from the previous post for 'table' parameters.

For the definition:

Code: [Select]

#x=1 "Param X" {a b c} table

The script variable will contain:
- x[1] = "a"
- x[2] = "b"
- x[3] = "c"
- x.index = 1, 2 or 3 (based on user selected value)
- x.value = "a", "b" or "c" (based on user selected value)

Phil.

table_param.diff (1.89 kB - downloaded 26 times.)

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

msl

1280
A720 IS, SX220 HS 1.01a

Re: Proposed changes to script parameters

« Reply #36 on: 11 / January / 2015, 07:34:46 »

Agreed, nice solution. Thanks for your patience.

msl

Logged

CHDK-DE: CHDK-DE links

philmoz

3450

Re: Proposed changes to script parameters

« Reply #37 on: 11 / January / 2015, 16:56:41 »

Quote from: msl on 11 / January / 2015, 07:34:46

Agreed, nice solution. Thanks for your patience.

msl

I've added this to SVN in revision 3911.

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

reyalp

14110

Re: Proposed changes to script parameters

« Reply #38 on: 28 / March / 2015, 21:25:46 »

For completeness:
In trunk 4117, I made a change to hopefully correct a case where "table" values were incorrect if you used "Load default param values"

http://chdk.setepontos.com/index.php?topic=11081.msg121443#msg121443

Logged

Don't forget what the H stands for.

waterwingz

12140

Re: Proposed changes to script parameters : subtitles

« Reply #39 on: 12 / September / 2015, 01:55:00 »

I have one (final) change to suggest to this topic prior to 1.4.0 going into lockdown & release mode.

With some of the more complicated scripts using most of the available 26 lower case single character variable as script @params, and with 1.4.0 breaking that 26 character limit, there seems to be a need to be able to group (or label) @params values to make them easier for the user to understand and use.

In offline conversations with philmoz, we discussed adding the ability for a script to have seperator lines in the Script menu parameter display. Something that could also have a string value that defines what the next section of @param values do. After a few code iterations by philmoz, it seemed that the cleanist & easiest way to implement this was to just allow the @title macro to be used multiple times in a script (Lua or uBASIC), with each instance creating a named separator to help guide the end user about what each section of @param values does.

I guess I can post code examples and screen shots of what this looks like, but I rather suspect this is all obvious to those who might care?

philmoz & I discussed fancier formatting options (right & left justify, different seperator characters, invert, color, etc) but that tended to complicate things where this simple patch should be sufficient. philmoz's patch file is attached.

Comments ?

script_subtitle_V2.diff (6.74 kB - downloaded 28 times.)

Logged

Ported : A1200 SD940 G10 Powershot N G16