Interface Value

Question

I want my interface to display a value in a text field (text field #2) that is the same value as a different text field (text field #1). The purpose is to save the user time so he doesn't have to type the information twice. 
 Text field #1 saves to a RULE INPUT called RECORD. Text field #2 saves to a RULE INPUT called EQUIPMENT. 
 The interface is ignoring the value displayed in text field #2, even though it displays a value in text field #2. As a result, no value is stored in my CDT for text field #2. 
 My process model has a "Write to" for both RULE INPUTS and everything is going good except for this one thing that I want to carry from text field #1 to text field #2. 
 
 Here is text field #1: 
 a!textField( label: "Training Event", labelPosition: "ABOVE", value: ri!record.trainingevent, <<<<<<<<<<<<<<<<<<<<<< saveInto: ri!record.trainingevent, characterLimit: 255, showCharacterCount: false, required: false ), 
 
 Here is text field #2: 
 a!textField( label: "Training Event", labelPosition: "ABOVE", value: ri!record.trainingevent, <<<<<<<<<<<<<<<<<<<<<<<< saveInto: ri!equipment.trainingEvent, characterLimit: 255, showCharacterCount: false, required: false ),

GopalK · Answer

HI, You would need to save 2nd rule input value in first text field's saveInto parameter like below, 
 a!textField(
label: "Training Event",
labelPosition: "ABOVE",
value: ri!record.trainingevent, <<<<<<<<<<<<<<<<<<<<<<
saveInto: {
ri!record.trainingevent,
a!save(ri!equipment.trainingEvent,ri!record.trainingevent)
},
characterLimit: 255,
showCharacterCount: false,
required: false
),

Here is text field #2:

a!textField(
label: "Training Event",
labelPosition: "ABOVE",
value: ri!equipment.trainingEvent, <<<<<<<<<<<<<<<<<<<<<<<<
saveInto: ri!equipment.trainingEvent,
characterLimit: 255,
showCharacterCount: false,
required: false
),

Mike Schmitt · Answer

Gopalk's solution is probably the correct one for your use case, but it will help if you understand a bit more about what's happening here. 
 In Appian, for any user input field, the "saveInto" parameter only has any effect whatsoever when the user directly interacts with that field. What you've done here, on the other hand, will cause the "field #2" value to always show the value of ri!record.trainingevent , and if any changes are made to it from that field, only then will the changes save only to "ri!equipment.trainingEvent", but those changes will not be reflected in the field itself since its value is set to only reflect ri!record.trainingEvent . 
 Instead, per the code GoalK posted already, we have the first "training event" field save any user input directly into both data targets simultaneously. Then the "field #2" value is changed to correctly reflect its own value, and any changes to that field will change only its value. This will roughly accomplish the behavior you're after. 
 The one thing to be careful of here, though, is that if the user enters a value in Field 1, then makes an edit to Field 2's value, but then also goes back and edits Field 1 again, the new value for Field 1 will overwrite the Field 2 data without caring that it already has a value. If this is your intent, then that's fine, but if there's a chance this will cause further user confusion, then you will need to refine the Field1 saveInto to avoid overwriting Field 2's value if it's anything other than "blank".

Mike Schmitt · Answer

louiss0005 said: Appian requires direct user interaction in a field for a value to even register in the field and become savable 
 Yup! 
 louiss0005 said: Gopal skipped thinking about anything else by simply saving the value of text field #1 on behalf of text field #2 
 He (and I both) assumed this is what you were after, per your initial phrasing. If your requirement is different in some way, just let us know and we'll help you figure out what more to add. 
 louiss0005 said: saveInto will allow me to save an array of saves if I use the {} and a!save to describe the second save item 
 Yes, and this is an important part of how powerful Appian interfaces can be with a bit of custom tuning, once you get used to the nature of the way these work.