Skip a blank line break

[Ian Murphy]

I'm sure this one is rudimentary, but I don't know it-

In an address database, I'm including a button which loads the currently selected record to the Clipboard, so that it can be pasted into a formal letter as text. The address information is stored as discrete fields; I have an extra field [AddressCalc] which is a calculation, returning text, which simply lists the pertinent information, separated by line breaks. What I want is to tell the box to skip the line break if there is no information there. For example: I have two Address lines, since some addresses need

E. Allan Poe

1313 Mockingbird Lane

(-->) Road C, PH B

Baltimore, MD 19999

Others, though, don't need that second address line; but the calculation listed above puts it in anyway:

George Bush

1600 Pennsylvania Avenue

(-->)

Washington, DC 20202

Should I be writing this differently? How to explain that, in the latter example, only one carriage return should appear between the words Avenue and Washington?

[Lee Smith]

Hi Ian,

You need to use the "Not" isEmpty in your caluculation.

LeftWords(

Case(not IsEmpty(Name), Name) &

Case(not IsEmpty(Address1), "

[Ian Murphy]

Brilliant!

This is what the Internet is for, as far as I'm concerned.

[kenneth2k1]

Hi:

Have you considered making a layout of you formal letter in FileMaker? Or is this not possible?

[Vaughan]

(BTW I'm not criticising you here Ian...)

I personally consider multiple address fields bad design. It annoys me. Yet I've seen it in small "amateur" systems as well as multi-million dollar corporate systems.

I typically have two or four fields depending on whether it's a local or an international address: local is "street", "city', "state", "postcode"; international is "address" and "country" because foriegn addresses usually don't adhere to the other four-field format very often, and having one field for everything except country gives a lot of flexibility.

The "street" and "address" fields can have as many lines entered into them as is necessary, and it avoids the problem of having to concatenate multiple fields together later.

What does everybody else do?

[Ian Murphy]

I think I see what you're getting at - I'm accustomed to setting up address DBs with several fields because in a work environment, it allows them to be quickly sorted [by last name, by company name, by ZIP code, etc.]. It seems to me, in fact, that like most decisions involved in setting up a database - or any informational source - it's a question of balancing flexibility against tedium, and finding the happiest middle ground. But your four fields are close to my, er, five [for me, Add1, Add2, City, St, ZIP {=postcode}]. Perhaps we're more alike than different?

[kenneth2k1]

Vaughan, I am in agreement with you. But I can see that there might be a need for an extra line for address.

Me personally, I use merge fields on my letter layouts set as one text group so that if one field is blank, the fields below it slide up. I also have two sets of address fields and a system to determine which set is the mailing address but that is beside the point.

[Vaughan]

"But I can see that there might be a need for an extra line for address. "

But from a data design perspective, that extra field isn't going to always contain the same info. Besides, in FMP fields can hold as many "lines" as is required to a max of 64KB.

If there is a need to have the company name, make a "CompanyName" field. If there is a need for contact name, make a "Contactname" field (which my databases usually have BTW). But "Address1" and "Address2" are meaningless and cause more trouble when trying to perform finds and create envelope and letter layouts.

But, in the end, it's whatever works or whatever the client wants.

[Lee Smith]

Hi Vaughan,

It sounds like the file has already been created with the two address lines,

Lee

[kenneth2k1]

Vaughan said:

"But I can see that there might be a need for an extra line for address. "

But from a data design perspective, that extra field isn't going to always contain the same info. Besides, in FMP fields can hold as many "lines" as is required to a max of 64KB.

That is true. And I don't use this extra line for an address. However, the reason that I can see it might be nice is because if the extra info runs on to the next line, it could cause a problem for some places.

For example, I remember when I was in the Army, the address we had to use was

::Name::

D co 232 Med BN

2 Platoon

Ft Sam Houston, TX 78234

If it were:

D CO 232 Med BN 2 Platoon

Ft Sam Houston, TX 78234

it might have been a problem, and I would probably be doing more pushups! It seems stupid, and the mail would have gotten to Ft. Sam Houston, but some places here want it done a specific way.

I think we are splitting hairs, but I am just trying to explain why a second address line might be necessary

Ken

[dbruggmann]

Theoretically I go with Vaughan (just one address field with multiple rows) for logical reasons.

But in practice I use only one line fields, because I had more than once trouble with address fields containing linebreaks. The most desastrous one: We export subscriber addresses from a Mac to a tab delimited text file and send it by mail to a Windows machine for printing labels, where about a half dozen hidden linebreaks were miss interpreted as additional tabs. Some hundred copies of our magazine were completely undeliverable, but we realised it only, when they were all coming back. It was a puzzle game to sort out the correctly delivered addresses and the scrambled ones.

[Ugo DI LUCA]

I use 2 lines too.

One is Main the other Complement where PO Box, Industrial Complex, Appt, Building is stored....

[Oldfogey]

Vaughan,

I could not disagree more re address fields.

I have membership DBs with both work and home addresses, an option to nominate which to use, and a 'final' calculated postal address which includes the name as well as the address. On top of all that, there is an override address field to 'fix' the postal address if necessary. (The most common fix is to abbreviate the institution name in a work address.) Using a single field for each address would be a nightmare.

Multiple lines have never caused me any trouble.

How does your single field, with paras, export for bulk mailing? (I'm too lazy to check it myself.)