Imported from previous forum
A percentage parameter raw value is expressed as a decimal like 0.45 to represent 45% (which may be multiplied by 100 for wire values if the flag is set).
Is it correct to assume validation rules would also specify decimal values?
If the control associated with the parameter is a spinner, would the increments and initValue also be the decimal values?
increment="0.10" initValue="0.50"
vs increment=“10” initValue=“50”
Is it correct to assume state rules would also specify decimal values?
A percentage parameter raw value is expressed as a decimal like 0.45 to represent 45% (which may be multiplied by 100 for wire values if the flag is set).
Is it correct to assume validation rules would also specify decimal values?
If the control associated with the parameter is a spinner, would the increments and initValue also be the decimal values?
increment="0.10" initValue="0.50"vs increment=“10” initValue=“50”
Is it correct to assume state rules would also specify decimal values?
Validation rules would also specify decimal values since these types of rules are intended to validate what goes over the wire.
For state rules I think the rendering engine should take an agnostic approach when evaluating state rules. WHich raises an interesting question: we are using Edit elements within StateRule elements to achieve flow control, what types of values should be used for Edit@value? The answer depends on the type of the control, referred by Edit@field, and should follow the following convention:
SIngleSpinner_t: use the value obtained directly from the control
TextField_t: use the value obtained directly from the control
Clock_t: use a value derived from the controls value and conforms to xs:time
SingleSelectList_t: use the enumID from the set of ListItems that corresponds to the selection
DropDownList_t: use the enumID from the set of ListItems that corresponds to the selection
Slider_t: use the enumID from the set of ListItems that corresponds to the selection
CheckBox_t: use “True” or “true” when the checkbox is checked, use “False” or “false” when unchecked
CheckBoxList_t: a space delimited list of enumIDs corresponding to the selection
(This list is incomplete. It would make a great addition to the spec .)
To illustrate, here are two use cases where the algo provider wishes to enable/disable a control based on the value of another control where they expect a percentage value to be entered:
In the first case the expectation is that the user will enter a value from 0 to 100 into the spinner control. So when determining whether to disable the other control the value of “66” is used for Edit@value.
In the next case the expectation is that the user will enter a value of between 0 and 1, the value “0.66” is used for Edit@value.
In both cases it seems that the rendering engine should not care that the underlying parameter is a percentage. The processing required to perform flow control can just accept the value of Edit@value as is.
Does anyone else concur?
-Greg
But should this parameter / control combination be allowed? In this case we ues a “Percentage_t” parameter with an expectation of 0.00 to 0.99. But then associate it with a control that ranges 0-100. While the state rule would be fine, there would be no way to know to divide by 100 when generating the parameter value from the UI.
<lay:Control ID=“c_pctVol” xsi:type=“lay:SingleSpinner_t” label=“%Vol (0-100)” parameterRef=“PercentRawl”/>
<lay:Control xsi:type=“lay:TextField_t” ID=“c_SOC” label=“Some other control” >
<flow:StateRule enabled=“false” value=“{NULL}”>
<val:Edit field=“c_pctVol” operator=“GT” value=“66”/>
</flow:StateRule>
</lay:Control>
A percentage parameter raw value is expressed as a decimal like 0.45 to represent 45% (which may be multiplied by 100 for wire values if the flag is set).
Is it correct to assume validation rules would also specify decimal values?
If the control associated with the parameter is a spinner, would the increments and initValue also be the decimal values?
increment="0.10" initValue="0.50"vs increment=“10” initValue=“50”
Is it correct to assume state rules would also specify decimal values?
Validation rules would also specify decimal values since these types of rules are intended to validate what goes over the wire.
For state rules I think the rendering engine should take an agnostic approach when evaluating state rules. WHich raises an interesting question: we are using Edit elements within StateRule elements to achieve flow control, what types of values should be used for Edit@value? The answer depends on the type of the control, referred by Edit@field, and should follow the following convention:
SIngleSpinner_t: use the value obtained directly from the control
TextField_t: use the value obtained directly from the control
Clock_t: use a value derived from the controls value and conforms to xs:time
SingleSelectList_t: use the enumID from the set of ListItems that corresponds to the selection
DropDownList_t: use the enumID from the set of ListItems that corresponds to the selection
Slider_t: use the enumID from the set of ListItems that corresponds to the selection
CheckBox_t: use “True” or “true” when the checkbox is checked, use “False” or “false” when unchecked
CheckBoxList_t: a space delimited list of enumIDs corresponding to the selection
(This list is incomplete. It would make a great addition to the spec .)To illustrate, here are two use cases where the algo provider wishes to enable/disable a control based on the value of another control where they expect a percentage value to be entered:
In the first case the expectation is that the user will enter a value from 0 to 100 into the spinner control. So when determining whether to disable the other control the value of “66” is used for Edit@value.
In the next case the expectation is that the user will enter a value of between 0 and 1, the value “0.66” is used for Edit@value.
In both cases it seems that the rendering engine should not care that the underlying parameter is a percentage. The processing required to perform flow control can just accept the value of Edit@value as is.
Does anyone else concur?
-Greg
In taking a variation of the example earlier, both parameters are Percentage (by default raw 0.45 on the wire). The same 2 controls used (both single spinners or even text fields if we want). Is there a way for the control to know whether it should show 0-100 or 0.0-1.0?
<lay:Control ID=“c_pctVol1” xsi:type=“lay:SingleSpinner_t” label="%Vol (0-100)" parameterRef=“PctVol1”/>
<lay:Control ID=“c_pctVol2” xsi:type=“lay:SingleSpinner_t” label="%Vol (0.0-1.0)" parameterRef=“PctVol2”/>
Yea - In my current code my spinner and text field controls for percentage parameters always show the values in x100. The setValue and getValue on the controls use the raw value (i.e. 0.45) but then show 45 in the control.
Cathy - I believe if you loaded this into atdl4j or Atdl4net, parameter PctVol1/control c_pctVol1 would work as expected, but PctVol2/c_pctVol2 would be misleading, as the spec would expect the user to enter a value between 0 and 100. If you really wanted a one-to-one correspondence between UI and FIX value, you could:
a) Set multiplyBy100 to true on the Percentage_t parameter
b) Use an alternative type, e.g. Float_t