Dialog Launching
The following describes the behavior when you attach a button on the KF UIStyler dialog to a child rule in Fusion. When the button is pressed it realizes that it is associated to a child rule and goes to look for a .dlg file that matches the class of the child. This allows a KF UIStyler dialog to display additional dialogs for child classes.
If the KF UIStyler interface can find a .dlg file that matches the name of the class of the child rule then it displays the new dialog and allows you to input parameters. Pressing OK or Cancel returns you back to the parent dialog. You can nest down multiple levels and all of the concepts for a KF UIStyler dialog apply to the children.
When you invoke the subdialog it automatically creates a temporary instance of the rules if that has not already occurred. This automatic action is as if there were a refresh callback on the button. This is required for technical reasons because in order to output parameters to KF from the subdialog it has to put a dynamic rule over an existing rule in Fusion. In order for that to work the child needs to exist - so it creates a temporary copy.
When you press OK or APPLY in the child dialog it never runs the full UG update. It applies any parameter changes to KF, and either exits the dialog with OK or in the case of Apply it updates the dialog presentation with any changes. Since you are not in the primary parent dialog, doing a full UG update may cause update errors if all parameters are not entered or changed as yet. Therefore, you do not see geometry updates when you hit OK or Apply in the child dialog. That only happens in the main parent.
Hitting cancel in the child dialog only exits the dialog.
When you get back to the main parent dialog - then OK and Apply causes the full UG update and realizes any child dialog parameter changes.
Given this information it is worth looking at how parameter values are passed and updated in the child rule.
Button named "aaa" to launch the child dialog.
UI/Styler File SubClass.dlg:
Two Number fields named "parm1" and "parm2"
When the child dialog displays, the initial value of parm2 is 0.0, and the initial value of parm1 is 10. If the value of parm1 is changed to 99 and you choose OK in the dialog - then a new dynamic rule writes over parm1 to set the value to 99. This dynamic rule overrides the value of 10 that was set by the parent and passed as a parameter to the child. As long as that dynamic rule exists the value remains 99. The only way to get rid of the dynamic rule is to delete it using the VDE, in which case the value goes back to 10.
Note the following when creating a child class that updates with a KF UIStyler dialog:
The parameters (like Parm1 and Parm2 ) need to have the modifiable attribute - otherwise the dialog cannot overlay the dynamic rule.
The parameters cannot be canonical, because you can't put a dynamic rule over a canonical parameter.
It is not necessary for the control values to be formal parameters. It can just be a "local variable" in that class as long as it has a modifiable attribute set. Making it a parameter is more consistent, but not required.
For example, the following situation would also work as a variation from what was shown above using local variables instead of parameters in the child class:
DefClass: MainClass ...
(child) aaa: { class, SubClass }; # no parameters passed
DefClass: SubClass ...
(number modifiable) parm1: 0; # just local attributes
This is somewhat different from how you deal with rules and parameters for top level classes and dialogs (at the root level). For top level classes all of the values do need to be parameters for the class, they can be canonical, and they do not have to be modifiable.
*x_direction: + 
