Imported from previous forum
I would like to know if there is a way that 2 controls in different StrategyPanels can reference the same value. In other words, if the value on a control changes should also change the value on another control.
I would like to enable the 1st control in a strategy panel called ,‘Basic Parameters’, and when another strategy panel called ‘Advanced Parameters’, then the 1st control is hidden and the 2nd control is enabled/visible under Advanced Paremeters with the value set in the 1st control.
It seems current ATDL doesn’t provide a way to do so. So, whenever I switch from 2 panels, the values need to be set again.
Please advise.
Thanks !
I would like to know if there is a way that 2 controls in different StrategyPanels can reference the same value. In other words, if the value on a control changes should also change the value on another control.
I would like to enable the 1st control in a strategy panel called ,‘Basic Parameters’, and when another strategy panel called ‘Advanced Parameters’, then the 1st control is hidden and the 2nd control is enabled/visible under Advanced Paremeters with the value set in the 1st control.It seems current ATDL doesn’t provide a way to do so. So, whenever I switch from 2 panels, the values need to be set again.
Please advise.
Thanks !
Namgyun,
I don’t have a definitive answer, but thought of a few areas. We created a high level of isolation (interface) between controls / widgets on the screen, and parameters that are to be packaged up and placed on the FIX wire. So, my first impression is this should be relatively easy.
There was a concept of a “helper control” - essentially a control/widget that was part of the UI but had nothing to do with a parameter on the wire. It held a value as part of the user experience but was “disposed of” as the message on the wire was being constructed. There may be some documentation covering “helper controls” that could be of help.
Greg may be swamped, or out on vacation but I’m sure he too would have some ideas if this doesn’t cover it.
Rick
I would like to know if there is a way that 2 controls in different StrategyPanels can reference the same value. In other words, if the value on a control changes should also change the value on another control.
I would like to enable the 1st control in a strategy panel called ,‘Basic Parameters’, and when another strategy panel called ‘Advanced Parameters’, then the 1st control is hidden and the 2nd control is enabled/visible under Advanced Paremeters with the value set in the 1st control.It seems current ATDL doesn’t provide a way to do so. So, whenever I switch from 2 panels, the values need to be set again.
Please advise.
Unfortunately only applies to a , and is not a Control, rather it contains Controls (or other StrategyPanels. A relatively easy way to accomplish what you want would be to use strategy panels, provided your FIXatdl renderer supports them. You could set Basic to collapsed=“false” and Advanced to collapsed=“true” and let the user simply collapse/expand on their own.
The following FIXatdl works (tested with atdl4j SWT edition), however, you have to specify a StateRule on every Control within the Basic and Advanced StrategyPanel section.
<?xml version="1.0" encoding="utf-8"?>
lay:StrategyLayout
<lay:StrategyPanel orientation=“VERTICAL” border=“None” collapsible=“false”>
<lay:StrategyPanel orientation="HORIZONTAL" border="Line" title="Basic vs. Advanced" collapsible="false">
<lay:Control ID="c_ShowBasic" xsi:type="lay:RadioButton_t" label="Basic" initValue="true" radioGroup="g_BasicVsAdvanced" tooltip="Show Basic Parameters"/>
<lay:Control ID="c_ShowAdvanced" xsi:type="lay:RadioButton_t" label="Advanced" initValue="false" radioGroup="g_BasicVsAdvanced" tooltip="Show Advanced Parameters"/>
</lay:StrategyPanel>
<lay:StrategyPanel orientation="HORIZONTAL" border="Line" title="Basic Settings" collapsible="false">
<lay:Control ID="c_BasicParm1" xsi:type="lay:TextField_t" label="Basic Setting #1" parameterRef="BasicSetting1">
<flow:StateRule enabled="false" visible="false" value="{NULL}">
<val:Edit field="c_ShowBasic" operator="EQ" value="false"/>
</flow:StateRule>
</lay:Control>
</lay:StrategyPanel>
<lay:StrategyPanel orientation="HORIZONTAL" border="Line" title="Advanced Settings" collapsible="false">
<lay:Control ID="c_AdvancedParm1" xsi:type="lay:TextField_t" label="Advanced Setting #1" parameterRef="AdvancedSetting1">
<flow:StateRule enabled="false" visible="false" value="{NULL}">
<val:Edit field="c_ShowAdvanced" operator="EQ" value="false"/>
</flow:StateRule>
</lay:Control>
</lay:StrategyPanel>
</lay:StrategyPanel>
</lay:StrategyLayout>
</Strategy>
Hi all, I know this thread has been for a while, but I would like to ask is there a way in ATDL for a control to get the value from another control? Is there something like a “getValueFrom” attribute that we can use so that controls are populated by the values set to other controls by the user.
<lay:Control ID=“SomeTextFieldControl” xsi:type=“lay:TextField_t” parameterRef=“ParameterForThisControl” getValueFrom=“AnotherControl”/>
Jay,
There may be a workaround, but I don’t think what you are thinking of was envisioned directly in the 1.1 spec. FIXatdl was platform “agnostic” and pretty “minimalist”, so dynamic connections between controls were kept pretty basic.
The only 2+ controls to 1 parameter envisioned during development were radio buttons.
One “Binding” as more fully described below is:
Control element -> parameterRef attribute
BINDS with
Parameter element -> name attribute
You can’t bind 2+ controls with a single wire parameter, and there is no (easy) way you can get controls to communicate with each other (one, where one messages and updates the other), so both are kept in sync along with a value down on the wire) as best I can see.
Controls can however INITIALIZE with a FixField value IF that is available at that time:
…attempt to initialize with the value of the tag specified in initFixField…
if … it’s not possible to access the value of the specified fix tag then revert to using initValue.
If …initValue is not defined, then do not initialize.
More snips from Greg’s documentation below.
Stuff in “Flow” (as in work flow…the process a human trader “fills out the order ticket”) may give you some clues for a possible work around.
Rick
Snips:
In order for an E/OMS to generate an order message it must iterate through all the parameters, find the associated controls, retrieve the control values and determine appropriate values with which to populate the custom FIX tags of the order message. In order for this to be accomplished FIXatdl provides a means for relating controls to parameters, mainly, the parameterRef attribute of the Control element. This attribute is set to the value of a Parameter‟s name attribute, thus providing a binding between the two.
Bindings of controls to parameters may be either
one-to-one, where one control is bound to one parameter, or
many-to one, where multiple controls are bound to one parameter.
[BUT…](The only cases of many-to-one bindings involve groups of radio buttons. All other bindings are one-to-one.)
…
not all controls need to be bound to a parameter. Controls with no declared parameterRef attribute are considered Helper Controls. They are used to manage the state of other controls via the use of flow-control rules.
[WORK FLOW RULES]
In order to standardize the way these rules are described we have provided a sub-schema which contains elements and attributes used to define rules that can be applied to the visual state of GUI Controls. This capability is a means to the user’s workflow and this is why it has been called “flow control”. When creating flow-control rules the expectations are that they are evaluated every time a Control‟s value has changed. Based on the outcome of the evaluations, certain GUI controls may become grayed-out or hidden as the user enters values into text fields or selects items from drop-down
lists.
[I liked the part about evaluated every time a control’s value has changed.]
Flow-control rules can be described via the StateRule element. A StateRule will consist of
a Boolean expression and
an action to take when the Boolean expression is true.
There are three actions that are supported:
(1) change the “enabled” state of a control to either True or False;
(2) change the “visible” state of a control to either True or False; and
(3) change the current value of the control to a supplied value.
(Supplied values may be
a constant string value,
an enumID,
or the special token {NULL}.)
…Also note how the EnumPair/@EnumID attributes match with the ListItem/@EnumID attributes. This creates the binding between the enumeration values of the parameter and the items of a drop-down list.
Hi Rick,
Thank you for your elaborate and clear reply.
I was also thinking of using StateRules for control communication, but as 1.1 spec mentioned, we can set current control’s value via StateRule, but this is limited to constant string, enumID or {NULL}. This seems doable for enumPair based controls (ie. radio buttons, check boxes, drop down) or pre-defined-value based controls. But TextFields on the other hand are “freeform” control, and I think StateRule might be difficult to use to communicate with TextFields.
I guess the only solution for now is to re-structure/organize our algo and avoid using parameter dependencies especially for text-based parameters.
Thanks a lot!
Jay