Proposed changes to script parameters - page 4 - General Discussion and Assistance - CHDK Forum

Proposed changes to script parameters

  • 52 Replies
  • 22656 Views
*

Offline reyalp

  • ******
  • 14125
Re: Proposed changes to script parameters
« Reply #30 on: 29 / December / 2014, 13:06:37 »
Advertisements
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.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
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
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #32 on: 10 / January / 2015, 16:52:22 »
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.
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)

Re: Proposed changes to script parameters
« Reply #33 on: 10 / January / 2015, 17:19:13 »
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.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #34 on: 10 / January / 2015, 17:30:44 »
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 »
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)

*

Offline philmoz

  • *****
  • 3450
    • Photos
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.

   
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)

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Proposed changes to script parameters
« Reply #36 on: 11 / January / 2015, 07:34:46 »
Agreed, nice solution. Thanks for your patience.

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #37 on: 11 / January / 2015, 16:56:41 »
Agreed, nice solution. Thanks for your patience.

msl

I've added this to SVN in revision 3911.

Phil.
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)

*

Offline reyalp

  • ******
  • 14125
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
Don't forget what the H stands for.

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 ?


 
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics


SimplePortal © 2008-2014, SimplePortal