Form like report

[Leif]

I've developed some Access forms that are "form-like". In other words, I
have multiple text fields stacked vertically. I wish somehow these fields
could grow, but in forms they are not allowed to dynamically grow. So my
work-around is to allow the user to double-click the field to show the entire
content of the field without having to scroll through the field.

In reporting grow works fine. However, the kicker is that Access reports
will cut a field into two parts if it straddles a page boundary.

I've read suggestions of this forum that one way to is split each text field
into separate groups where the header, detail, and footer sections are used
to separate the growing text fields. However, with about 40 or 50 text
fields that may grow this seems very ackward. 50 would require 17 groups. I
don't know the limit on the number of groups, but I suppose that could also
become an issue.

Does anyone have an idea for a work-around?

Thanks,
Leif

 

[Klatuu]

Steve Lebans is the best there is with this sort of thing. Go to this site
and download the example database that demonstrates how to simulate Growing
on a form:

http://www.lebans.com/cangrow.htm

 

[Marshall Barton]

I've developed some Access forms that are "form-like". In other words, I
have multiple text fields stacked vertically. I wish somehow these fields
could grow, but in forms they are not allowed to dynamically grow. So my
work-around is to allow the user to double-click the field to show the entire
content of the field without having to scroll through the field.

In reporting grow works fine. However, the kicker is that Access reports
will cut a field into two parts if it straddles a page boundary.

I've read suggestions of this forum that one way to is split each text field
into separate groups where the header, detail, and footer sections are used
to separate the growing text fields. However, with about 40 or 50 text
fields that may grow this seems very ackward. 50 would require 17 groups. I
don't know the limit on the number of groups, but I suppose that could also
become an issue.

I think you might be out of luck on this one, The number of
report groups is limited to 10 and you only get one header
and one footer per group. There is exactly one detail
section regardless of the number of groups. So, with 10
groups, you can get a maximum of 21 separate sections that
will keep together on their own page. I think the best you
can get with this arrangement is to put two or three text
boxes side by side in each section.

A different arrangement that might be viable is to use some
subreports to get another 10 groups per subreport, Then the
main report can get 21 keeptogether subreport sections for
each main report section. More than a little messy, but I
think it will do the job.

 

[Leif]

This is no fun...

Perhaps the MVPs can suggest this as an upgrade to Access. Perhaps a
do-not-break property for text related controls. It won't do me any good,
but perhaps it will help some person down the line...

 

[Marshall Barton]

This is no fun...

Perhaps the MVPs can suggest this as an upgrade to Access. Perhaps a
do-not-break property for text related controls. It won't do me any good,
but perhaps it will help some person down the line...

That suggestion has been made more than once, but
KeepTogether is already complicated enough. Just getting
KeepTogether to work in subreports where page related stuff
is severely limited is somewhat amazing.

Note that you will probably exceed other limits with a table
that has 50 some text fields. E.g. a single record can
contain a little less that 4K of data. So, if your 50 Text
fields can average no more than about 80 characters.

Your situation is normally dealt with by using multiple
tables in a 1-1 relationship. This table structure makes
using subreports much more straightforward.

 

[Leif]

Thanks for the 4K limitation information. I was not aware of that.

I my particular case, however, the text will be absent or very short. I was
wondering if something like what was done for forms, in Klatuu's post, could
be done in reports (lebans's Can Grow database form)? In otherwords,
analysize the size of the text field and if it looks like it will split to
the next page next force it onto a new page? Not easy, if it is possible,
but it is a more general solution, although it might not work across
subreports.

 

[Marshall Barton]

I my particular case, however, the text will be absent or very short. I was
wondering if something like what was done for forms, in Klatuu's post, could
be done in reports (lebans's Can Grow database form)? In otherwords,
analysize the size of the text field and if it looks like it will split to
the next page next force it onto a new page? Not easy, if it is possible,
but it is a more general solution, although it might not work across
subreports.

You can do that in reports too, but with 50 text boxes, it
can get more that a little complicated in either a form or a
report. Not only that, but forms do not have to worry about
page boundaries.

You can use Stephen Lebans' TextHeightWidth function in a
sections Format event to get a very good estimate of the
height that a text box will be after it grows.

Working from top to bottom of a section and keeping track of
the accumulated heights and spaces between the text boxes
thus far, you can compare the eventual size of a text box to
the report's Top property (that provides the section's
position on the page) and then make a page break control
visible to push the text box to the next page.

Personally, I have to advise against that idea and recommend
using subreports instead.