![]() | |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
This may be a silly question, but here goes... I was looking at a merge field in a file that I had found and noticed the syntax was something like this: First Name[1] From what I could see it was trying to use a merge field based on a specific value for an indexed key field. Can anyone tell me if this is possible? |
#3
| |||
| |||
|
|
On 2010-01-12 07:47:39 -0800, Elry <elryal... (AT) gmail (DOT) com> said: This may be a silly question, but here goes... I was looking at a merge field in a file that I had found and noticed the syntax was something like this: First Name[1] From what I could see it was trying to use a merge field based on a specific value for an indexed key field. Can anyone tell me if this is possible? It's not silly if you've never seen it. The [1] is a reference to the first repetition of the field. Look at the field def and you may see that it's defined to repeat. Normally the first repetition doesn't need to be referenced with a number, it's the default. *If you have data in the third rep of the field and you want to show it in the merge field, you'll see <<First Name[3]>> as the merge field. The rep is inserted when selecting the field in the dialog. The entry field at the bottom of the dialog lets you access the repetitions for fields defined that way. -- Lynn Allen --www.semiotics.com Member FBA FM 10 Certified Developer |
#4
| |||
| |||
|
|
Now I understand what the syntax is for... Let me pose another question: Is it possible in a Merge field to specify which record number value will be used to return a value to the merge field? In other words If I had a number of merge fields as labels - could I then store the label values as data values that can be selected at "run time". |
#5
| |||
| |||
|
|
On 2010-01-12 09:09:31 -0800, Elry <elryal... (AT) gmail (DOT) com> said: Now I understand what the syntax is for... Let me pose another question: *Is it possible in a Merge field to specify which record number value will be used to return a value to the merge field? In other words If I had a number of merge fields as labels - could I then store the label values as data values that can be selected at "run time". This is a little confusing as to what you're wanting to do. Merge fields always show the contents of a field *on the record you are on.* If a field is a calc that shows another record's field values, such as a GetNthRecord then the merge field will show that. Or you can store your data in repeating fields, say all the French labels are in repeat 2, and the Russian ones in repeat 3. Then when you want to switch labels, have the a group of calc fields that interpret a repeat number in a global, and show the merge fields based on the calcs. Merge fields do not store data or display it separately from the underlying field. -- Lynn Allen --www.semiotics.com Member FBA FM 10 Certified Developer |
#6
| |||
| |||
|
|
Let me explain a bit further... What I am trying to do is create a multi-lingual solution. I would like to store all the labels in one table and then reference that table based on language selection. So if I have 20 fields on a form - somewhere I would have a table with the 20 fields listed and and say maybe 4 translations per field label. I would like to be able to use merge fields to change the labels "on the fly". Your idea about using repetitions looks viable, but my difficulty comes in selecting the right record for the right field. |
#7
| |||
| |||
|
|
On 2010-01-12 10:05:09 -0800, Elry <elryal... (AT) gmail (DOT) com> said: Let me explain a bit further... What I am trying to do is create a multi-lingual solution. I would like to store all the labels in one table and then reference that table based on language selection. So if I have 20 fields on a form - somewhere I would have a table with the 20 fields listed and and say maybe 4 translations per field label. I would like to be able to use merge fields to change the labels "on the fly". Your idea about using repetitions looks viable, but my difficulty comes in selecting the right record for the right field. Well, then merge fields are really beside the point. What you need in your label reference table are three fields. 1. Language *- Spanish, English, French 2. Label name *- First Name, Last Name (in your base language) 3. Label value *- "First Name", "Nombre Primero", "Nom de un" (can you tell I can't speak French?) So each record will have one language, one label name and one label value.. Make a bunch of global fields. These will display the labels. Name them in your base language, the language you develop in. *Make one global the gLanguageToReference global. Make another global the gLabelName global. The rest of the globals will be named the same as the label value they will hold. *So you will have globals named "First Name", "Address", and "Invoice Total" if those are the labels you want. Now make a relationship from the global table to the label reference table where gLanguageToReference = Language, and gLabelName = Label name. Fill the gLanguageToReference with a value, the language name. Then go to a layout that contains all those global fields. If you've named them with names the same as the names of the Label name fields, you can run a looping script to go to the first field, set the gLabelName global equal to Get(ActiveFieldName), and then set the global itself with the value from the relationship for Label Value. Loop through the rest of the label globals and reset that second field to pull the correct value each time. *Perform this script on login each time. If a user resets the language during the session, repeat this script. *By setting the values into globals on launch, you don't have to incur any performance hit as users move from layout to layout and calculations refresh. You can use merge fields based on the globals to display if you want, or you can use the fields themselves. This also works for button text. Just put a merge field or the actual field on top of the button. Using globals means that you can display those values no matter what Table Occurence your records are from with no additional relationships. However, you lose the values when in Find mode, so be careful. You may want to program around users needing Find mode. -- Lynn Allen --www.semiotics.com Member FBA FM 10 Certified Developer |
![]() |
| Thread Tools | |
| Display Modes | |
| |