Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

ACCESS VIOLATION!!

edited March 2003 in General
Using RB Pro 7.01+D6.02 RTL 2.

I found the following bug: saving report to an archive (both using the
built-in RB devices or Extradevices ones) AFTER printing gives an AV. You
can reproduce it in your demos, dmmain.pas, changing the procedure
spbPreviewPrintClick as follows:

procedure TfrmDMMain.spbPreviewPrintClick(Sender: TObject);
begin
ppViewer1.Print;

// add the following lines to force a subsequent print to archive
with ppViewer1.Report do begin
ArchiveFilename:='C:\abc.arc';
AllowPrintToArchive:=true;
devicetype:=dtArchive;
ShowPrintDialog:=false;
Print; // #2
end;
end; {procedure, spbPreviewPrintClick}

you'll see that the print #2 will result in a AV for ANY report you'll
choose from the demo ones. An AV is produced also if you cancel the printing
from the print dialog.

Any workaround? Thanks!

Sandro

Comments

  • edited March 2003
    It is not an AV, it is an exception that is raised. What is happening is
    that you are calling Viewer.Report.Print. The Viewer.Report property could
    be any TppProducer descendent, such as TrsClientReport, TppReport,
    TppArchiveReader or TppDBArchiveReader. In this demo it is a
    TppArchiveReader. Calling ArchiveReader.Print is going to try to open
    C:\abd.arc and not generate it. You need to use a TppReport and call
    Report.Print in order to generate an archive file.


    Cheers,

    Jim Bennett
    Digital Metaphors


  • edited March 2003
    Thank you Jim for the clarification. I definitely solved the problem using a
    pointer to the original report; without your suggestion i could never figure
    what could be the problem ^_^

    Ciao, Sandro
This discussion has been closed.