Home› General
ReportBuilder 22.06 now available including Delphi 12.2 support!
New Blog Posts: Merging Reports - Part 1 and Part 2

Access Violation

rbuserrbuser
edited November 2003 in General
Hi,



I have created a report which prints spreadsheet style (basically print the
report to cache, re-order pages and then send it to the printer). This
report is used by a number of people and for the majority there are no
problems but a couple of users have got access violations. We have a
package which we use called JCL which emails us with information about where
the error occured. It seems to always occur just before the
Pppdlg.TppPrintDialog.InitializePrinterControls reportbuilder procedure.
What does this do? Do you have any idea why it might be falling over here
(I know its a long shot but thought I would ask anyway)? I am currently
looking into whether all the users who get this error are on Citrix (we have
a proportion of users using Citrix) but thought I would try and find out
some information about it. Thanks in advance.



Richard

Comments

  • nicociziknicocizik
    edited November 2003
    Hi Richard,

    Sorry, this is not a known issue with ReportBuilder. Are you able to
    determine where in the InitializePrinterControls routine, the application is
    causing an AV? Which version of ReportBuilder are you using?

    --
    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • rbuserrbuser
    edited November 2003
    Hi,

    We are currently using reportbuilder 6 but will be upgrading soon. I can't
    tell exactly where it is happening but will keep investigating. Thanks for
    your help.

    Richard

  • rbuserrbuser
    edited November 2003
    Hi Richard,

    I have seen something similar to this. Here is the situation that caused
    the problem. The user tried to print a report and found that the printer
    that they wished to send it to was not installed. With the application
    still up, they added the printer and tried to print it again. At this time
    the printer dialog box logic attempted to populate the list of printers for
    the printer dialog. At this point we would get the access violation. You
    should be able to re-create this scenario in a simple project to see if the
    av is in the same place. Our work around was to add 'ppPrintr' to the
    'uses' and then just before the '.Print' we called
    'ppPrintr.ppPrinters.Refresh' to re-establish the RB internal list of
    printers. You could also check for the count of printers found at startup
    and again just before calling Print and only refresh the list conditionally.

    Hope this helps.

    Regards,
    Chuck Van Acker
    Alogent Corp.
This discussion has been closed.