Calculating Number of lines in a text field?

[Steve J]

Here is a question that has me stumped... I am generating a database that replicates a paper form. The form has several main text blocks on the first page, and continuation blocks on the following pages. I would like to allow the user to enter all the text into one field in an "entry" layout, and intelligently "split" the text into the main and continuation fields on the printable form. I've tried combinations of character-counting and linebreak counting, but can't figure it out. Is this even possible?

[ESpringer]

I would use two calc fields which split an original text at some word-count cutoff (which avoids splitting a word):

cTextStart = [color:"green"] LeftWords(text,200)

cTextRemainder = [color:"green"] RightWords(text,WordCount(text)-200)

A complex variation takes the Length of the field (in characters) and divides it by the word count to yield an average word length for this field, so that your 200 number could bump up or down depending on whether your text-writer is unintelligibly overdetermined to overutilize extravagantly polysyllabic vocabulary, necessitating adjustments.

So replace 200 above with [color:"green"] (Length(text)/WordCount(text) * 40) or whatever works...

You can do this for each of your fields... Of course, you make the cutoff conservative so that the words in cTextStart won't usually *saturate* the field... do you really need to run right into the bottom corner?

For printing, I'd recommend making the actual fields non-printing, and using a block of merged text for your text start. This way, you can add a cont'd flag (number calc field that shows the word count in excess of your cutoff, and format it as Boolean non-zero=cont'd...) at the end of your merged text, perhaps in a smaller size italic or whatever... it will make it obvious that the dangling few words on the last line don't mean a paragraph break or the end of the data.

You may also want to build in "orphan protection" by making the initial box include the WHOLE text if its word count goes beyond the default cutoff by 3 words or less... it's silly to have the spillover show only a word or two...

But say why what you've tried "hasn't worked" -- maybe you have a different problem or requirement...?

[BobWeaver]

It is possible, but it gets complicated because even without linebreaks, long chunks of text will wrap around and produce several lines. It's too late at night for me to explain all the details (I have to go to bed) but the basic idea is to arrange copies of your text fields on special layouts--one field per layout. The fields are formatted exactly the same as they appear on your main form, in fact they should be copied from the original form just to make sure they are exact copies. Place the field on the layout so that the bottom comes exactly at the page break. Then stretch the field a bit longer so that it crosses the page break by a line or two, but make sure that you don't make the field any wider.

Do this for all your text fields, one layout per field.

Make a script that does this:

1. Go to the layout for your first field.

2. Go to the record you want to format. Omit the record, then show all records. This makes that record the only one in the found set.

3. Now go into preview mode.

4. Go to the last page.

5. Find the page number using the status(CurrentPage) function.

6. If it is greater than 1 then your text is more than will fit in the first field. So go back to browse mode, chop off a few words and put them in the second field. Then go back to step 3 and repeat until you get a page count of 1.

7. Now repeat the whole process with the remaining text in the second field on the second layout.

8. And repeat the process again until you have filled up all your fields or run out of text.

It's complicated, but I have done this before and it works. This is something to think about and get you started.

Now, I'm going to bed. Have fun!

[Steve J]

"But say why what you've tried "hasn't worked" -- maybe you have a different problem or requirement...?"

Unfortunately, the fields I need to split usually hold a list of different items, any one of which may be more than one line. For instance:

1. This is the first item

2. This is the second item, which goes on and on and potentially takes up more than one line or even two if the person is particularly long winded

3. A short one.

So... counting words won't do it, and counting carriage returns won't do it. Seems like this is a good candidate for version 7.

Thanks!!

[Steve J]

I think this qualifies as a "brute force method"... but it may work in my case. I'll try it out.

Thanks!

[ESpringer]

I see... funny how I projected my own likely uses (pretty saturated paragraph-blocks with lots of soft-wrap) onto your situation, which was completely different.

BobWeaver's solution is certainly electronic elbow-grease at work...

(I think he meant to suggest Show-All then Omit-Record then Show-Omitted in Step 2, in case someone less experienced tries to follow the directions...)

Best of luck with it!

[BobWeaver]

Yes, that's right. I forgot that the user may be starting off with a partial found set.

By the way, I know this technique tends to look really bad, but it does have the advantage of giving an exact result, even accounting for different size fonts, different character formatting, paragraph formatting, hard returns etc.

I've used it a few times when I needed to be sure that text would fit properly into a field.