Is there a way to get around the 253 character limit (I believe that's what it was) when creating a clac. I have an e-mail template that i use which is about 600 characters. Kinda a pain to make calcs and then combine them all together (using 4 fields sincei can't use 1). ideas? Thanks

quote:

---

Originally posted by Fitch:

A text calc that's giving you the message:

"This text constant... is longer than 253 characters."

... can be fixed by dividing your calc up with ampersands like so:

"long string of text" &

"another long string" &

"YA string of text etc."

You can construct a huge length of text this way. I

think

it is limited the way other text fields are: only by memory (Up to 64,000 characters).

---

Bingo, this was the problem. I thought the field was limited to 253 characters, but i was the string of text. By putting a " & " it'll make it happy. Well who wouldve guessed. Once again, Thanks guys!

Bad programming technique? Sometimes, but it's not hard to think of examples where it's perfectly suitable, for example constructing HTML or RTF files. Or perhaps restoring some default value, such as an AppleScript.

Are you trying to put the whole body text of the email into your calculation formula? Why not store the body text in a global field and then reference the global field in the calculation.

Or, are you just concerned that the result of the calculation is limited to 253 characters? If so, no need to worry, the result can be up to 64000 characters long.

A text calc that's giving you the message:

"This text constant... is longer than 253 characters."

... can be fixed by dividing your calc up with ampersands like so:

"long string of text" &

"another long string" &

"YA string of text etc."

You can construct a huge length of text this way. I think it is limited the way other text fields are: only by memory (Up to 64,000 characters).

But, it's just bad programming technique to put such a huge text constant into a calculation, especially when chances are very good that it will have to be changed from time to time.

I stand by my comment about bad programming. When you have a text constant that's longer than 253 characters, it's no longer some fundamental constant like a carriage return or a tab, it's DATA. And data should be stored in a field.

I've spent countless hours fixing up someone else's programming mess because they put all their data into calculation formulas. Things like the body text for emails; things like company name and address of the end user etc. Then, when we wanted to adapt the solution to a different client, we had to search throughout literally hundreds of calculations and layouts to change names and other client specific data that would have been dead simple if someone had simply created a few globals at the beginning of the project to store these kinds of things. There may sometimes be limitations in the programming environment that requires you to do some ugly programming, and Filemaker isn't perfect, but there is no reason I can think that forces you to put huge text literals into calculation formulae.

There! I've had my rant!

quote:

---

Originally posted by BobWeaver:

I stand by my comment about bad programming. When you have a text constant that's longer than 253 characters, it's no longer some fundamental constant like a carriage return or a tab, it's DATA. And data should be stored in a field.

I've spent countless hours fixing up someone else's programming mess because they put all their data into calculation formulas. Things like the body text for emails; things like company name and address of the end user etc. Then, when we wanted to adapt the solution to a different client, we had to search throughout literally hundreds of calculations and layouts to change names and other client specific data that would have been dead simple if someone had simply created a few globals at the beginning of the project to store these kinds of things. There may sometimes be limitations in the programming environment that requires you to do some ugly programming, and Filemaker isn't perfect, but there is no reason I can think that forces you to put huge text literals into calculation formulae.

There! I've had my rant!

---

I totally understand where you're coming from. But in my case it's for my own use, and I suppose i could create several global fields, but to me that's that many more fields that i need to deal with. So that's my $.02, in reply to your $.02. Thanks!

BW, here is the beginning of a script that emits RTF:

"{rtf1ansi{fonttblf0fswiss Arialf1fswiss Arial}

{stylesheet

{adjustright f1fs20cgrid snext0 Normal;}

{s15tqctx4320tqrtx8640adjustright f1fs20cgrid sbasedon0 snext15 header;}

{s16tqctx4320tqrtx8640adjustright f1fs20cgrid sbasedon0 snext16 footer;}}"

And that's just the beginning! There's a bunch more of such loveliness, and while I agree in general with your sentiments, this is one case where it just doesn't seem advantageous (or even prudent) to create fields to hold this stuff. It's too easy to mess it up!

Hey Fitch, I never said that I'm a good programmer!

There's exceptions to every rule. If you know for sure that the text will never ever ever change, then okay. But, there is another reason to keep long text constants out of calculation fields. It keeps the calculation shorter and (hopefully) easier to read. For example:

"{rtf1ansi{fonttblf0fswiss Arialf1fswiss Arial}

{stylesheet

{adjustright f1fs20cgrid snext0 Normal;}

{s15tqctx4320tqrtx8640adjustright f1fs20cgrid sbasedon0 snext15 header;}

{s16tqctx4320tqrtx8640adjustright f1fs20cgrid sbasedon0 snext16 footer;}}" & MydataField & "par }pardwidctlpar {f5 par }trowdtrqctrgaph108trleft-108 clbrdrtbrdrs yadda yadda...."

or:

gPreamble & MyDatafield & gPostamble

Re: making calcs easier to read. I hear ya! It's a trade-off. In this case the calcs are hairy, but the script is full of comments, like so:

Set Field (gText, "blah..")

# Thus ends the header.

Set Field (gText, gText & "more blah...")

# Forsooth, 'tis the footer

etc.