Expanding Text Blocks

[Jacob]

Ok, I'm having a new problem with printing. I have a small form where Users can enter in text. As they type, the text box will automatically scroll so that they can type as much as their little hearts desire. The problem I'm having comes when I try to print these forms. I'd like the layout to expand the part to fit in all the text so that it will print nicely. I've tried making the fields very large, and setting them to slide. This works most of the time, but some Users seem to type more than I thought possible - is there any setting that let these fields expand to fit the text in preview/print mode?

Thanks

[Vaughan]

Nope, fields do not expand they can only shrink.

Generally I use a separate data entry screen optimised for on-screen viewing, and a separate print layout optimised for printing. On the print layout the field objects are always significantly bigger than I expect is required, which are then formatted to shrink down to fit the actual data entered.

[Leader]

Could you use a calc text field for printing that assembles and concatenates all the other fields? You could strictly control the shape of the output.

[ezra]

That's an intersting thought, but can the size of the text field on the print layout change per the result of the calulation? I did not think this was possible...

[Leader]

No, the calc field doesn't change size, but what I an getting at is since this is targeted toward printing, you would combine several fields, and optionally use FM7's great formatting functions to enhance sections. Compris?

In other words, you wouldn't necessarily know the lengths of individual newspaper articles, so it's not reasonable to block out fixed columns in advance.

However, replacing fixed fields with one calc field is more like flowing columns with Pagemaker. The calc field simply gathers all the columns and assembles them according to the specifications of the formula your provide.

[spb]

Could you not get the same effect by placing merge fields on your print layout instead of regular fields?

Steve Brown

[Leader]

Are you still talking within FM?

I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution.

That's not to say others may not serve as well.

[Leader]

Are you still talking within FM?

I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution.

That's not to say others may not serve as well.

[Leader]

Are you still talking within FM?

I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution.

That's not to say others may not serve as well.

[spb]

Yes, I am talking within FM. In similar situations, I placed merge field versions of my fields directly on the layout. The result can act like the large concatenation field you describe. Each individual field will expand or contract as needed.

There are other reasons your concat field may work better, though.

spb

[spb]

Yes, I am talking within FM. In similar situations, I placed merge field versions of my fields directly on the layout. The result can act like the large concatenation field you describe. Each individual field will expand or contract as needed.

There are other reasons your concat field may work better, though.

spb

[spb]

Yes, I am talking within FM. In similar situations, I placed merge field versions of my fields directly on the layout. The result can act like the large concatenation field you describe. Each individual field will expand or contract as needed.

There are other reasons your concat field may work better, though.

spb