Discussion Forums

Re: Percentage Controls
Steve Wilkinson / Cornerstone Technology Limited
6 Jan 2012 7:00AM ET

I agree with Greg - as a principle, I assume that everything to do with controls will use the value as seen by the user, and everything to do with parameters will use the wire value.

In fact, I was just doing some work with Atdl4net and I realized that the Percentage_t implementation wasn't quite right when it comes to handling multiplyBy100. The spec is silent on whether minValue and maxValue should use the wire value of the parameter or the wire value multiplied by 100 (if the attribute is set to true). Using the above principle, I interpret that the value sent over FIX should always be used when considering parameter constraints. (Of course, this is arguably mute as multiplyBy100 is deprecated.)

In terms of Cathy's original example, my interpretation is that increments and initValue should use the values as seen by the user, and NOT decimal/percentage values. The same applies to State Rules. However StrategyEdits relate to wire value and they should use the decimal/percentage value for Percentage_t types.

Hope this makes sense & is obviously open to correction by anyone older/wiser.

-Steve.

> > 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.
>
> <Parameter name="PctVol" xsi:type="Int_t" fixTag="7645" use="optional"/>
> <lay:Control ID="c_pctVol" xsi:type="lay:SingleSpinner_t" label="%Vol (0-100)" parameterRef="PctVol"/>
> <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>
>
> 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.
>
> <Parameter name="PctVol" xsi:type="Float_t" fixTag="7645" use="optional"/>
> <lay:Control ID="c_pctVol" xsi:type="lay:SingleSpinner_t" label="%Vol (0-1)" parameterRef="PctVol"/>
> <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="0.66"/>
>         </flow:StateRule>
> </lay:Control>
>
> 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


Percentage Controls
Cathy Mildenberger / Neovest, Inc.   4 Jan 2012 4:24PM ET
Re: Percentage Controls
Greg Malatestinic / Jordan & Jordan   5 Jan 2012 12:15PM ET
Re: Percentage Controls
Steve Wilkinson / Cornerstone Technology Limited   6 Jan 2012 7:00AM ET
Re: Percentage Controls
Cathy Mildenberger / Neovest, Inc.   10 Jan 2012 5:22PM ET
Re: Percentage Controls
Steve Wilkinson / Cornerstone Technology Limited   11 Jan 2012 3:27AM ET
Re: Percentage Controls
Cathy Mildenberger / Neovest, Inc.   11 Jan 2012 10:44AM ET
Re: Percentage Controls
Steve Wilkinson / Cornerstone Technology Limited   11 Jan 2012 10:57AM ET
Re: Percentage Controls
Cathy Mildenberger / Neovest, Inc.   11 Jan 2012 11:10AM ET