Subreport Memofields stretching past bottom of page

rbuser

Greetings,
I have a situation where currently a subreport that is often near the
bottom of the report page contains a single memofield only. The
memofield is usually going to contain at least half a page or more of
notes related to the datafield that it links to.
In almost every case the memofield starts to print on what little is
left at the bottom of the page and then as expected continues on the
following page.
But when the memofield continues on the next page it has picked up at
least a sentence or two past where it stopped on the prior page, thus it
is clipping a few sentences or more from the text that should be
displayed on the report.

My question is whether or not there is a setting that I can apply to
this to ensure that it does not clip?
I have tried the 'KeepTogether' option but there are two of them. One
for the subreport field as listed on the main report and another for the
memofield within the subreport tab. Which one takes precedent? If the
text of the memofield is longer than one whole page how does it
'keeptogether?'

If there is a RAP solution to this whereby there exists check conditions
I can employ should I redirect this question to the rap newsgroup?

Thank you for any help you can provide on the matter.


Joe Grubs

nicocizik

Which band is the subreport located in your main report. Does the text of
the memo change in a master-detail relationship or are you printing a number
of different memos in a row? I'm a bit unclear about what you mean when you
say that a couple lines are being clipped. Are you actually missing lines
of the memo on the second page or is it starting lower on the next page than
you would like. In my testing in RB 10.05 with a large stretchable memo in
a subreport, the memo picks up right where it left off when a new page
begins.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:



Nico,
Thank you for getting back to this so quick.
The subreport is one of several within the Detail band, all placed
within their own dedicated and selfcontained regions.
The regions contain labels and in some case dbtext fields which
accompany the subreport.
They are placed in regions so that both the subreport and any
accompanying labels or fields will shift relative to the next region and
it's subreport.
The regions are all set to stretch as are the memofields.

By 'clipped' I mean that lets say the memofield contained 20 lines worth
of text.
Immediately upon selecting preview I would at first see lines 1,2 & 3 at
the bottom of the page within what little space was left.
Then suddenly lines 2 & 3 would disappear leaving only line 1 before the
preview was finished generating.
I assumed that lines 2 & 3 had been shifted onto the next page on the
second pass even while that had been visible on the first page during
the first pass.
When I view the second page I see that it picks up at line 4 but line's
2 & 3 are missing. Page one has line 1 but page two picks up at line 4
and lines 2 & 3 are completely gone.

Thank you.

Joe

nicocizik

Hi Joe,

I have not seen this behavior before. Which version of ReportBuilder and
Delphi are you using? Are you able to recreate this issue in a minimal
example, perhaps using the DBDEMOS database? If so, please send the example
to support@digital-metaphors.com in .zip format and I'll take a look at it
for you.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:


Nico,
The problem seems to stem from the reformatting that is occuring on the
second pass. When I turn off the second pass option from the Report>Pass
Setting in the menu the problem does not happen. I think what is at
issue here is that there are essentially 3 lines of text on the first
page during the first pass. When the second pass begins the pass is
reformatting the report and is removing(or shifting downward) two lines
leaving only the first line of text, but is then not adding those two
shifted lines back onto the second page. It's as if they are getting
lost in the process. Maybe the reformatting of the second page is not
accounting for the fact that some content from the first page had to be
added to the second before it then began reformatting that second page
prior to the second page moving on to the third page and reformatting it.
The fact that this is a memofield embedded within a subreport which in
turn is embedded within a region might have something to do with it
cause we have a region that must stretch across two pages and the
memofield within the subreport must stretch as well over those two pages.

In regards to the DBMemos database, there is no way to reproduce the
data in this case because it is quite unique and because there is
private medical information being produced in these reports there are
federal confidentiality laws in effect so I cannot send screenshots nor
zip up the report sample and send it to Digital Metaphors support.

Perhaps if you could explain what all is being done on the second pass
and whether the report can exist without a second pass may be the only
solution I have at this point.

Thank you for your help to this point.

Joe

nicocizik

Hi Joe,

The first pass of the report is simply to define pagination and perform any
pre-calculations you might need to do. The second pass will not effect how
the report prints unless there is some code to alter it perhaps in an event
handler somewhere.

As a test, try commenting out all your event handlers and see if the the
problem still occurs. If not, periodically begin adding the event code back
to try to isolate where the problem is occuring.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:



Nico,
Unfortunately this did not work. After further study of the problem I am
getting the impression that somehow the process is unaware that it is
clipping the text because it is probably not accounting for the footer
band right below it when it calculates how much space is left for it to
print.
Thus my next question is this.
How does report builder know where to stop and where to pick up again on
the next page?
Are there index counts of a particular property relating to the location
within the memofield data?
Line counts? Perhaps character counts?
Would it be possible to find out what this count is and simply adjust it
so that on the next page it picks up where it left off +/- two or more
lines/characters where it thinks it left off on the first page?
How does RB identify each of the memofields on both pages when it is
split in this case?

Should I take this question to the RAP newsgroup?

Thanks for all the help.

Joe Grubs

nicocizik

Hi Joe,

Please understand that it is very difficult for us to track down an issue if
we cannot recreate it on our machines here. Trying to figure out what is
happening on your machine is more or less like taking a shot in the dark.
It would be very helpful if you could give us a simple example of what is
occuring (perhaps with some made-up data).

ReportBuilder will measure the amount of space available for a stretchable
item on a page. In the case of a memo, it calculates the number of lines
that can fit and stores that position to continue generating lines on the
next page. In all of my tests with simple reports, this seems to be working
correctly with and without the footer band present.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com