Registering a new PDF-renderer - bug?
Hello,
we wanted to register a slightly modified PDF renderer for images. To do
that we used TppPDFRendererManager.RegisterRenderer which always
resulted in an access violation when the register routine was called.
An investigation of TppPDFRendererManager.RegisterRenderer showed that
this method wants to remove e previously registered renderer from the
list. And that seems to be the problem:
The loop that searches for a previously registered renderer runs from
zero to Count-1. Inside the loop an item may get deleted if it matches
the given renderer class. If an item was deleted you get an access
violation when the loop reaches the last iteration!
Shouldn't that loop run backwards (Count-1 to zero)?
Ciao,
Ralf
we wanted to register a slightly modified PDF renderer for images. To do
that we used TppPDFRendererManager.RegisterRenderer which always
resulted in an access violation when the register routine was called.
An investigation of TppPDFRendererManager.RegisterRenderer showed that
this method wants to remove e previously registered renderer from the
list. And that seems to be the problem:
The loop that searches for a previously registered renderer runs from
zero to Count-1. Inside the loop an item may get deleted if it matches
the given renderer class. If an item was deleted you get an access
violation when the loop reaches the last iteration!
Shouldn't that loop run backwards (Count-1 to zero)?
Ciao,
Ralf
This discussion has been closed.
Comments
You are correct. I made this change in a patch for RB 14.08. Send an
email to support@digital-metaphors.com to receive the updated file.
This will also be included in the next release of the ReportBuilder.
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com