D3 to D7 Problem - Read of address 0000000

rbuser

Hi,

I am converting a project from D3/RB3.52 to D7/RB7.02 and I need help with
three problems. I use RTM files and load them as required from files.

Problem 1. - Printing a single page invoice.

If the invoice has more than 25 detail lines, it prints a Footer band on the
first page and a Summary band on the final page. A Footer band always
prints at the bottom of the page but a Summary band just prints after all
the detail has printed. Maybe my programming is unorthodox but here goes..
In order to ensure that the Summary band is printed in the same position as
the Footer band, I have two ppRegions in the Summary band. Region2 contains
all the stuff I want printed at the bottom of the final page, and Region1
contains a ppMemo that I add blank lines to in order to increase the height
of the Summary band. As Region1 is set to stretch and Region2 moves relative
to Region1 it has the effect of pushing the details in the Summary band to
the bottom of the page. While I realise that there may be easier ways of
doing this, the invoice was designed some time ago and is already with my
customers. The Problem - since converting, the stretchable region doesn't
stretch..

Problem 2 - Printing a single page statement.

Much the same situation as above but different problem. The Region is
stretching, but the Footer band is printing. As this should be a single
page report and the Footer band is set to print on the first page but not on
the last page, it shouldn't print.
Strangely, the stretchable region is working OK.

Problem 3 - The Real Killer.

During the troubleshooting of these problems, I tried to launch the RB
Designer within the Delphi IDE and I get the following error:

Access violation at address 01D66617 in module 'vcldesigner70.bpl'. Read of
address 0000000

This error occurs twice before the designer opens, again when the report is
shown, and again when the designer is closed. It only seems to happen when a
report containing a PageStyle band is loaded and often requires a shutdown
of Delphi before a non-problematic report can be opened.

Any reports that are saved in DFM files are working OK and can be opened in
the RB Designer.when Delphi is launched. The RTM files are loading OK in
runtime, albeit with undesirable results, and no error messages are
generated.

I'm almost at my wits end, but I would welcome any suggestions.

Hopefully
Mike O'Grady

I use RTM files and load them as required from files. When I converted to
D7/RB7.02 and previewed a single page report (an invoice) I found that the
FooterBand was printing even though it is set not to print on the last page.

nicocizik

Hi Mike,

1. Instead of using regions to position the summary band, try using the
TppSummaryBand.PrintPosition property to define where you would like it's
position on the page to be. You can access this property through code or by
right clicking inside the summary band and selecting the "position" option.

2. Are you able to recreate this issue with one of our demos or with a
minimal report? In my testing, when I set PrintOnFirstPage or
PrintOnLastPage to False on a one page report, neither printed.

3. When The Report Designer initializes, it tries to directly load the
print driver that you have installed as the default printer. Try updating
to the latest print driver for the printer you are using.

--

rbuser

Hi Nico,

I did a little further digging and I'd like your opinion on the following
results.

1. Created a new project with a single form containing a TTable,
TDataSource, TppBDEPipeline, and TppReport.
2. Connected the TTable to the DBDemos database, Customer.DB table.
Connected the TDatasource to the TTable, the TppBDEPipeline to the
TDatasource, and the TppReport to the TppBDEPipeline.
3. Double-clicked the TppReport to open the report designer.
4. Clicked File - New Report and got - Access violation at address 01D66617
in module 'vcldesigner70.bpl'. Read of address 0000000
5. Figured that it must be my installation and uninstalled everything.
6. Reinstalled just Delphi and ReportBuilder and repeated the above steps
with the same results.
7. Created a simple list report from the above configuration and put a
rectangle in the Footer band so that I could see what was happening.
8. Previewed the report and the footer band was displayed. Ok so far.
9. Set PrintOnFirstPage to false and previewed the report again. The footer
band was not displayed BUT the vertical space where the footer band would
have been was not used by the report, i.e. the detail lines of the report
didn't print in the area where the footer band would have been if it had
been printed.

This is what caused my problem with the footer band printing on the single
page report when PrintOnLastPage was false. The "ghost" footer band is
causing the report to run to two pages. This even happens if both
PrintOnFirstPage and PrintOnLastpage are false. The only way to stop the
footer band from using the space is to make it invisible.

I would be interested in knowing if you, or any other forum readers, can
replicate this behaviour or is it just me.

Regards,
Mike

nicocizik

Hi Mike,

- We have never had an AV like the one you are getting at that specific
time. Which Edition of ReportBuilder 7.02 are you using? (ie. Standard,
Pro, Enterprise, Server).

- You might try creating a two pass report and in the Report.BeforePrint
event (in the second pass) you could check the Report.PageCount for only one
page. If the report ends up only have one page, you could set the
visibility of the footerband to False. Something like the following.

procedure Form.ReportBeforePrint(Sender: TObject);
begin
if Report.SecondPass then
begin
if Report.PageCount = 1 then
FooterBand.Visible := False;
end;

--

rbuser

Excuse me,

You had one before. (me!)

I recognize the error and get it the same way he does.

and I am using Standard edition.

Paul

rbuser

I might have found the source of the problem. The solution is up to you.....

When you have loaded a report it produces an AV in vcldesigner70.bpl.

BUT when you try to load the paramaters editor in the rightbutton menu of
the TppReport component you get an error : No editor registered for this
component and then stucks in the endless AV error loop again.

Also. When loading an pas file which contains a form with a TppReport
component it gives an AV when pressing Shift-F12 the first time. ( showing
the form )


Hope this helps cause it's a pain in the ass, because I don't like report
building this way

Paul

nicocizik

Hi Paul and Mike,

Thanks for reporting this issue. This is a design-time bug which we have
fixed for the next release. Thanks for your patience.

--

rbuser

when will the next release be put out ??

rbuser

What's the story Nico?

When is a problem a problem. When my customers report a problem, I take it
seriously. Digital Metaphors obviously has taken a different approach. As
one of your customers, I would expect that when I report a problem, you
would assume that I have taken some time to try to resolve it before
bothering you. The fact that Paul had to refute your assertion that you
never had this AV problem before, suggests that you are not particularly
interested in hearing about the obvious bugs in RB7.02. Also, if you had
acknowledged that the problem existed, I could have been spared the hassle
of uninstalling/reinstalling Delphi.

In relation to the "fix" you proposed for the FooterBand problem, it's not
exactly what I would have expected to hear from the experts. If you had
done a little research, as I ultimately did, you would have found that RB is
calculating the available space on the page BEFORE it checks to see if the
FooterBand is to be printed. This is a change from previous versions where
the available space was calculated after determining which bands were to be
printed. Sure, I could have found this without bothering you, but I assume
that your knowledge of the inner workings of RB would allow you to identify
the problem much more quickly than I could.

My problem with regions not stretching is due to a change in the timing of
the ppReportEndFirstPass event. In previous versions, this event could be
used to make changes to page contents. Not any more. If the changes that
are being made to RB were documented, users could instantly see where
changes in the timing of events have an impact.

All of my migration problems from Delphi 3 to Delphi 7 are related to
ReportBuilder, for which I paid an upgrade fee. Maybe I should have been
given a "downgrade refund".

I'm sorry for being so snotty and I HATE to be so aggressive but I have
products and customers to support and the "upgrade" to RB7.02 has been a
most painful experience, so much so that I have decided not to use it for
any future projects. I will resist the temptation to use your forum to name
a product which costs 60% less, has free upgrades, converted to D7
effortlessly, and upgrades give improved functionality. But if you guys
don't get your act together you won't be winning any awards in the future.
In fact, you may not have a future

Yours in frustration,
Mike O'Grady

rbuser

Okay DM,

I've always loved your product, far better then QReports or Rave reports
that was always included in Delphi.

Making reports in DM was always fun. I occasionally didn't know what to do,
but that was lack of experience of me. I always said : 'You wan't more
reports, okay I got a tool that kicks ass!'

But now, as of RB 7.02 it's a hell I can make reports. But whenever I try to
load one. It goes down on me. Erroring all the way.

You always thank for my patience, but it starts to run out.
You said to me : 'We have the fix for the Designtime errors, here is a file
for the run-time errors' I think. 'Wow! I didn't have any runtime errors,
it's the designtime errors that are killing my production'
Last thursday I used up 2,5 hours of my time to correct three pictures and
reposition them a bit. A job easily done in 3 minutes.

I'm not gonna demand anything. But I would like to tell you something. What
would you think when you are using a product which isn't functional for at
least 3 months, you've reported the problems several times. They tell you
they have a fix that would fix all your problems but they won't just give it
to you, yet.

Paul

nicocizik

Hello Gentlemen,

I assure the both of you we are working diligently to resolve this issue.
Thank you again for you patience.

--

nicocizik

Mike,

We are aware of the bug you detected and are working to resolve the issue as
quickly as possible. As this is a design time bug that only exists in the
Standard version of ReportBuilder, it will require that we create a new
release with the problem fixed. Being a developer yourself, I'm sure you
know this cannot be done over night.

I am very sorry for not realizing the change in the OnEndFirstPass event was
the reason for the problem you were experiencing. ReportBuilder 4 was
released over 3 years ago and it was an honest mistake that I had forgotten
about this change.

--