With drop down lists and pop up menus, this is possible as you can set up a value list where the first column of values is hidden so that the user selects a visible value, but the hidden value in the first column is what is entered into the field.
With radio buttons and checkboxes, it takes a different approach.
If you can arrage your radio buttons/checkboxes into a single vertical column, you can resize the field to be so narrow that only the values next to the circles or squares are not visible. You can then place label text on the layout in place of the value list text next to each one.
In other cases, it may be simpler just to have two fields. One stores the value entered from the value lists and the other stores/displays the desired substitute value.
You can look up value from a look up table.
A scriptTrigger can perform a script to enter the value.
A calculation such as:
Case ( RadioButtonField = "yes" ; "You are happy";
RadioButtonField = "no" ; "You are Unhappy )
Can display the matching value.
Note: Use FilterValues if you need to check the contents of a checkbox group formatted field in this way.
Thanks for the detailed answers, PhilModJunk.
Alternatively, is it possible to create a look up table containing the FieldName and the FieldCalculation and write a script that will look up the Field Calculation for a specific field each time it finds the field name in a merge field?
Can you explain what you have in mind in more detail? I'm not sure to what purpose you'd need a field calculation if you are going to look up the value.
If you have:
YourTable::RadiobuttonField = Responses::ValueSelected
You can have two records: Yes (in valueSelected ) with "you are happy" and No with "you are unhappy") and a text field in YourTable can then use this relationship to look up the text response appropriate to the value selected in the Radio button field.
I was thinking of having a look up table for the field calculations for each fields because multiple questions could have the same answers (e.g. "Yes") but still stand for different things (e.g., "Yes, you are happy" vs "Yes, you are tall").
I thought about creating duplicates of each fields and having the calculation done on the duplicated field (where "Field 1" contains the value selected and "Field 1 Copy" performs the calculation to generate the sentence), but it didn't seem like a very elegant/scalable solution when there are so many fields in the form.
I suggest that multiple quesitons should be placed in separate records with one question to a record as this makes it much easier to work with the responses. You may want to do a search of this forum using the keyword "survey" to see some discussions on table design strategies for surveys.
Assuming separate recors for each question: You can use a relationship that matches on two fields to select the response text appropriate for a given question.
YourTable::QuestionID = ResponseText::QuestionID AND
YourTable::RadioButtonField = ResponseText::ResponseValue
You also do not have to use a looked up value setting to copy the data into a field in YourTable. You can also just put the text field from the ResponseText table directly on your layout. With the first approach, editing the responseText records after the fact will not automatically update the text looked up into YourTable. With the second approach, any changes made in ResponseText will automatically appear on your layout.
I'm not sure if we'll be analyzing on the survey responses extensively yet, so I'm going to use the Case calculation approach that you mentioned earlier first to get a working version and get more familiar with the FMP. Thanks for all the great suggestions!