Hanno - thanks for the link.
Rakesh,
Was pulled away on other activities, sorry for the delay, but wanted to get back to you and find out if you got your checkbox / helper control working exactly the way you want it?
Sorry about the brief reference to the docs but wanted you to be sure you had them. Actually you need to study THREE things before things will begin to make sense with FIXatdl: the .pdf is very good but you should also look very carefully at the sample file for examples and it’s in-line documentation. Then you should spend some time looking at the actual .xsd source files themselves because they also carry extensive comments that can also be very helpful. All three of these sources (in the zip file in Hanno’s link), taken together, cover a lot of territory. I find myself using FIND on all three sources yields info that is easy to forget.
RULES are used in two areas. They were created for VALIDATION first, and only later developed and applied to the FLOW area with ample reuse. To make your checkbox and optional parameter on the wire work, you will be in the FLOW area, with the underlying Boolean logic reused from the VALIDATION area.
FLOW is all about user interaction DURING order build. (You can’t assume all parameters are populated yet, the order may only be partly built.) EVENT listeners are attached to controls (widgets) which raise a “change” event. FLOW RULES are fired by those change events. Every time – ANY control(s) containing a listener to a different control that fires – will cause that control’s rule to run. If the logic in that rule then evaluates TRUE, the prescribed change(s) in the state of that specific control will be made. (RULES that fire may cause other RULES to fire too.)
VALIDATION only occurs when the entire order is built, and the user has pressed the “send order button”. It assumes all parameters are filled in, and ready to go. Validation RULES are run all at once, covering all the parameters that are mentioned in the set of rules for that strategy. Here you must “jump over all the hoops” or an ERROR message is given to the user, and the order is not sent until they ALL are resolved.
Validation rules are defined via StrategyEdit elements, child of an entire Strategy Element. (Push send order, that entire strategy is going to be sent and executed, with all the currently standing parameters, UNLESS a StrategyEdit rule fails. Meaning the Boolean result of all the logic in the StrategyEdit rule returns FALSE.
Flow-control rules are defined via StateRule elements, child of a specific control (widget). When the user changes the value of a SINGLE control xxx, all RULES (StateRule) that contain Boolean logic that includes field=”xxx” will be listening for changes on “xxx”, and will run. So a change lay:Control ID=“xxx” may drive changes in 0 or more other Controls, including changing their value, which if bound to a parameter will dive change there too. (keep reading and loop back here if needed).
Each StateRule (FLOW) can only do one or more of:
(1) change the “enabled” state of its parent control to either True or False
(2) change the “visible” state of its parent control to either True or False
(3) change the current VALUE state of its parent control to a supplied value. (a constant string value | an enumID |the special token {NULL}) Note: {NULL} means “uninitiated” in a Control, and if that control is bound to a Parameter, it means OMIT the Parameter from the FIX WIRE message.
StateRules initiate the above change(s) when the underlying Boolean logic returns TRUE.
Admiditedly somewhat confusing: “field=” is used in the Boolean logic portion of both VALIDATION RULES (StrategyEdit) and FLOW RULES (StateRule) but morphs meaning, based on context
- In StrategyEdit (Validation) rules, “field=xxx” refers to a Parameter name=”xxx”
- In SateRule (Flow) rules, “Field=yyy” refers to a lay:Control ID=“yyy”
Controls are typically “bound” to Parameters (<lay:Control ID=“aaa” … parameterRef=“bbb”> meaning this Control named “aaa” will have a value that will be bound to the Parameter named “bbb”.
Controls that are not “bound” to Parameters (that lack the parameterRef="bbb” attribute) are referred to as “helper controls”. Their function is to aid the order build (FLOW) process only. They do not supply values that end up on the FIX Wire.
Head spinning yet? Its confusing initially because xml and .xsd can easily look like a pile of spaghetti code with many GOTOs. Work through the three sources a few times (.pdf .xsd and .xml in-file documentation) and things will eventually become a whole lot easier.
Rick
PS By using “not and” in the Boolean logic parts of rules you can even do some “computation”. Rules can also be named and reused, called in other rules, etc.
and as expected. Really appreciate your help on this.
