dbTalk Databases Forums  

Merge Fields

comp.databases.filemaker comp.databases.filemaker


Discuss Merge Fields in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Elry
 
Posts: n/a

Default Merge Fields - 01-12-2010 , 09:47 AM






Hi Folks...

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?

Thanks.

Reply With Quote
  #2  
Old   
Lynn Allen
 
Posts: n/a

Default Re: Merge FieldsX-TraceApproved - 01-12-2010 , 10:55 AM






On 2010-01-12 07:47:39 -0800, Elry <elryallen (AT) gmail (DOT) com> said:

Quote:
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

Reply With Quote
  #3  
Old   
Elry
 
Posts: n/a

Default Re: Merge Fields - 01-12-2010 , 11:09 AM



On Jan 12, 11:55*am, Lynn Allen <l... (AT) NOT-semiotics (DOT) com> wrote:
Quote:
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
Thanks Lynn...

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".

Reply With Quote
  #4  
Old   
Lynn Allen
 
Posts: n/a

Default Re: Merge FieldsX-TraceApproved - 01-12-2010 , 11:23 AM



On 2010-01-12 09:09:31 -0800, Elry <elryallen (AT) gmail (DOT) com> said:

Quote:
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

Reply With Quote
  #5  
Old   
Elry
 
Posts: n/a

Default Re: Merge Fields - 01-12-2010 , 12:05 PM



On Jan 12, 12:23*pm, Lynn Allen <l... (AT) NOT-semiotics (DOT) com> wrote:
Quote:
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
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.

Reply With Quote
  #6  
Old   
Lynn Allen
 
Posts: n/a

Default Re: Merge FieldsX-TraceApproved - 01-12-2010 , 01:17 PM



On 2010-01-12 10:05:09 -0800, Elry <elryallen (AT) gmail (DOT) com> said:

Quote:
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

Reply With Quote
  #7  
Old   
Elry
 
Posts: n/a

Default Re: Merge Fields - 01-12-2010 , 01:27 PM



On Jan 12, 2:17*pm, Lynn Allen <l... (AT) NOT-semiotics (DOT) com> wrote:
Quote:
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
Thanks Lynn...

I just tried it - and I can see a number of different possibilities.

Votre francais c'etait - "Not Bad".

Thanks Lynn - at least now I have a great starting point.

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.