merge fields; how do I shorten the text "box"?

[dlazenby]

Seeemingly simple question: I created a merge field (name) that consists of theses 5 individual fields: title, first name, middle name, last name, suffix. that would yield e.g. Mr. John Henry Doe, Jr.

My problem is that on the layout, in layout mode this text box takes up too much space on my layout. When I try to shorten it with the "handles" it just creates a 2nd line so that the "volume" of that text box is the same. This takes up too much space on my layout, cluttering the area, making it impossible to add adjacent fields on that line.

In contrast, if I insert a field onto the layout (by selecting the field button --> specify field), I can shorten that "box" on the layout that represents the field without a problem.

In the above example those individual fields that comprise the merge field are from a related table, so the "text box" that represents the merge field shows <<table::field name>> for all 5 individual fields. This is unwieldy to say the least.

Is there a way that I can create a merge field (? calculation function) in the related table so that I can bring it onto the layout as an "adjustable field" rather than as a merge field?

Please advise.

Doug Lazenby

[-Queue-]

It's only necessary for the first character of a merge field to be the desired size in Layout Mode. So the first < of each merge field should be the right size. You can shrink all other characters up to and including the second > for each field. This will save much space on your layout.

[dlazenby]

Pooh-Bah,

Thanks for the reply. I don't follow though. My merge field text box, e.g., <<table1::field1>> <<table1::field2>> <<table1::field3>> <<table1::field4>> <<table1::field5>> takes up a complete line of my layout and actually extends onto the next frame when I only want it to be allotted say 40 characters. Are you saying, keep the first character the desired format and then use an ultra small format (e.g. font size 1) for the remaining characters?

Doug

[-Queue-]

Yes, that's correct. The fields will look like <.... <..... <...., etc. This won't effect how they appear in Browse Mode either. It just allows you to cram them in nicely.

[ESpringer]

Gee, I always took out an axe and started hacking away at my field names and relation names/table names... thanks Queue!

[rockman]

I'm new to FM too. I would have thought it would be best to create a calculated field (as the original post suggested). Is this just a case of two different ways to do the same thing, or is there a definite advantage to using the merge field instead?

Thanks for your insights,

Jeff

[dlazenby]

Jeff,

I'm with you. This seems somewhat of a "kludge" (is that the right yiddish term a jerry-rigged solution?). If you have to recheck the merged fields you have to go back and change/rechange the font to be able to a readable size, although I guess you could just magnify it say 800%.

I would rather have a calculated field or some other alternative.

Doug

[dbruggmann]

The advantage of the merge field in a text written directly in layout mode, is that it slides automatically. If you have several such fields in a text to display it's almost impossible to achieve with the field tool.

If working in layout mode one can also change the display of the merge fields from <<name>> to real world values: => View menu => Show => Sample Data

[MoonShadow]

I also use the method Queue describes - learned it originally from one of Ray's sample files ... wanted to put a merge on a button but the merge field name was too long. He had it scrunched to like 1 pt. It is certainly not kludgy. And the text can easily be viewed in layoutmode by zooming in.

It allows the final text to be displayed in its full size but fit within the space needed for the final text - not the full field name (which is sometimes a relationship name as well).

A calculation instead of using merge? I guess you could. Detlev gave you reasons why merge is better; here are two more: 1) With merge fields, it is easy to change the color of each field within the merge - calculations (in 7) will require additional functions (within the calculation) to achieve it and 2) A calculation will use FM resources. Merge fields are underused in my opinion.

[dlazenby]

Moonshadow (and Detlev),

Thanks for your input/perspective on merge fields. It certainly is easier to use a merge field for me.

I posted a different related question on getting rid of the extra spaces between merge fields. Do you have a suggestion.

Specifically, if you set up a merge situation with more than 3 or more fields, with a space between each field and you have one or more blank inner fields how do you get rid of that extra space.

For example: merging FirstName, MiddleName, LastName; if the person has no middle name you are left with 2 spaces between first and last name. If you have an even longer (more fields) merge situation the potential is there for even more blank spaces which in my opinion looks bad.

Please advise.

Doug Lazenby

[MoonShadow]

Easy! Use a calculation! Sorry ... Merge fields are great but sometimes a calculation is still the best. You can create a calculation out of any fields which may be empty and on the same line, then include that Case() calculation in your merge field in place of those few fields per line ...

Or you can create a 'spacer' calculation in your merge line which considers your field contents and inserts a spacer only when necessary - but you would need one spacer calc for each possible 'in between possible empty fields' position. Then don't put manual spaces in those positions - place the spacer calcs instead in the merge between those fields. FM efficiency-wise and Developer time-wise, which would be better? Tough call - depends upon your data.

[MoonShadow]

I should explain what I mean by a spacer calc. Create a calculation (text) called cSpacer with:

If(not IsEmpty(MiddleName), " ", "") ... for < vs. 7

If(not IsEmpty(MiddleName); " ") ... for vs. 7

Then your merge line would look like:

<<FirstName>> <<MiddleName>><<cSpacer>><<LastName>>

Of course, one might forget to add the spacer and that is why I added turning your 'possible empty' field into a concatenated calculation (text) cMiddleName and using that in your merge:

MiddleName & If(not IsEmpty(MiddleName); " ")

<<FirstName>> <<cMiddleName>><<LastName>>

I tend to be obsessive at keeping calculations (and file size) as compact and efficient as possible and the spacer would seem a *bit* more efficient than including the MiddleName again in the calc. And you only need to do this if you have possible empty fields on the same line.