RB7 loops at end of page
First page prints/displays OK.
Second page goes into an endless loop in the following in ppDB.PAS since the
second CheckDetailData always returns FALSE.
RB6 did this, so I upgraded to RB7 - but same loop.
procedure TppDataPipeline.DetailSkipBackward;
var lbValidDetail: Boolean;
begin
lbValidDetail := CheckDetailData;
while not lbValidDetail and not(BOF) do
begin
SkipBack;
FDataTraversed := True;
lbValidDetail := CheckDetailData;
end;
Second page goes into an endless loop in the following in ppDB.PAS since the
second CheckDetailData always returns FALSE.
RB6 did this, so I upgraded to RB7 - but same loop.
procedure TppDataPipeline.DetailSkipBackward;
var lbValidDetail: Boolean;
begin
lbValidDetail := CheckDetailData;
while not lbValidDetail and not(BOF) do
begin
SkipBack;
FDataTraversed := True;
lbValidDetail := CheckDetailData;
end;
This discussion has been closed.
Comments
support@digital-metaphors.com
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
extract the failing report.
What kind of events should occur to allow CheckDetailData in
procedure TppDataPipeline.DetailSkipBackward
to return TRUE?
This is not a very large loop (it just lasts forever). If I knew what to
look for, perhaps I could help you isolate the problem.
completely on the previous page. The engine by default moves to the next
apge and then when this case is encountered it moves back one record to try
and print it. What component is part of the band that is breaking over onto
the second page? Find out the top starting position of the band or
component and try to mimic this setup in a test report using the demo
DBDEMOS database or contrive your own test data using the JITPipeline. Send
it to support@digital-metaphors.com If you could reproduce the problem in an
isolated report, then we can debug it and find out what is going on and fix
it.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
Earlier this year I encountered this problem with the same app. After
jiggering a number of properties, the loop went away. It is now back --
even after upgrading to RB7.
A cursory scan of Tamaraca shows that the following people have had the same
or a very similar problem:
6/15/01 Tom Van den Eynds
1/24/02 Roy Jonker
4/26/02 Lance Johnson
3/13/02 Ole Juhl
This in NOT a user's property problem or a user's data problem. This is a
catastrophic coding error in RB. It is even worse than an Access Violation
(which stops processing) since there is no warning or indication that the
error is occuring.
My earlier post identifies where RB is looping. I will now attempt to
identify where your code is failing.
report so that you get infinite pages.
If that doesn't help, then we really need to have the layout and some sample
data in front of us so that we can run this report to see which component
configuration is causing the problem. Once we have a better idea of what
your report is doing then we can help. Please send a demo to
support@digital-metaphors.com
Cheers,
Jim Bennett
Digital Metaphors
------------------------------------------------------
Article: TroubleShooting: Report Prints Endless Pages
------------------------------------------------------
Occasionally, we have customers state that their reports are in some
infinite state where page after empty page prints forever.
There are a few items to check when this occurs.
The TppReport.AutoStop property is the first thing to check. If this is
false when the DataPipeline property is unassigned, the endless report will
be the result. AutoStop is automatically set to True when DataPipeline is
set to nil, but it is possible to set it back to False. Check for instances
in your code where you might have created this condition.
Another thing to check is that all subreports in your report have their
DataPipeline set. When a subreport does not have its pipeline set, you will
sometimes see a condition where the first detail record prints and then you
get blank pages.
Another, non-data related cause can sometimes be your margin settings. If
you have stretching bands that need to overflow to the next page, if your
margins are too tight, sometimes the report engine will endlessly overflow
to the next page trying to fit the overflow material. As a test, try setting
DetailBand.PrintHeight to phDynamic. A dynamic height band can overflow to
additional pages as needed.
Still another cause might be having a statically positioned control, set to
ReprintOnOverFlow, in the same band with a stretching control. For instance,
if you have a memo set to stretch and in that same band, a label control set
to ReprintOnOverFlow, then on every page after the first, the memo will
begin to print after the label control. If the label is placed low enough
that the memo has no room to print, the report will forever be trying to
print the overflowing memo on the next page.
--
Tech Support mailto:support@digital-metaphors.com
Digital Metaphors http://www.digital-metaphors.com
http://www.digital-metaphors.com
info@digital-metaphors.com