This issue has been addressed in RB 7.04. If you need information on upgrading, please contact sales@digital-metaphors.com for more information. Note that this upgrade is free of charge if you have already purchased a version of RB 7.x.
The black image problem still exists in 7.04 I'm using it and can still reproduce the problem.
The sites that this affects are running the exe across a network. It therefore appears to be dependant on speed somehow, as a fast machine running the exe locally will not reproduce it. I'd suggest some code to check if the rendering of a page is complete before sending it to the printer for the next release.
The changes from 7.03 to 7.04 have reduced the problem from 1 in 2 to about 1 in 10 for our customers however it is still a significant problem.
Can you tell me if there is a way of getting this working 100%
What type of printer are you printing to? In the past we have found that certain printers do not handle images as well as others. The fixes made in ReportBuilder 7.04 greatly reduced the number of "black image" occurances with our customers but it did not solve the problem for every instance. Be sure the image you are using has its Transparency property set to False. You may also want to run your application through a memory checker such as Sleuth QA or MemCheck to be sure you are not leaking any memory or resources as this may cause the problem as well.
We have reports of black printing from an HP 640c, an HP 6122 and an HP business inkjet 2230.
Transparency is False on all images.
The app worked 100% on Report Builder 5.5 and only failed after a conversion to Delphi 7 where we had to move to Report Builder 7.
I don't think it is to do with resources, or memory leaks, as I've been through the code and I can't see any leaks in the area where the printing occurs and any that previously existed have been fixed. (ie. the Delphi 3 code has leaks)
On previous testing with the source code I could reproduce this using a break point in one particular part of the code to slow one part of the threading. 7.04 did not reproduce the same way however it still left me dubious about the threading. Are you relying on one thread finishing first? If so it should be checking the thread is complete prior to sending to the printers canvas. The fact that it does not reproduce with a local exe but does on sites with slower networks still points towards the threading.
There is no multiple threading occurring in ReportBuilder unless you are using RB Server or Background Printing. The main issue with loading images before 7.04 was that we were not globally locking the memory used for the image and it, on occasion, was being re-allocated by Windows elsewhere before the report had a chance to print. This was fixed in RB 7.04. This issue had been present in ReportBuilder since its conception so the fact that it worked in RB 5.5 for your specific case was purely coincedential. I still must insist that you run your entire application through a memory checker. The only reason that your images will show up black is due to a memory or resource leak. Also, you can try printing your report to an Archive and then printing that archive file. This will separate the image access from the image printing giving you an idea where the problem lies.
Running the entire application through a memory checker is not possible, the application is hugh (we are talking a 90Mb directory with the bulk of that being bpls). I can't see memory leaks being the problem, possibly overwritting memory yes but a leak? Maybe if you have used all the resources and memory but not probable especially with an NT code based OS. I'll see if I can reproduce the problem with a smaller exe with source.
Hi Nico, As promised I've a test application that can reproduce the problem.
Do you want the source mailed directly to you or in the group?
Be aware the problem was reproduce on an HP DeskJet 850C and took around 20 prints to get the black images to appear.
Notes on how I reproduced the problem.
I switched to print to a networked HP LaserJet 2200 Series PCL using the PCL driver at one point (probably a red herring as on site one customer can reproduce the problem using just to one printer locally on their own machine).
I run the print job from an exe on a network drive to simulate what the users have on site, though I've no idea if this has any bearing on the problem.
This is not a known issue with ReportBuilder 9.01. If possible try printing your report to a different printer and see if that helps. You may also want to try installing ReportBuilder to a different machine (Perhaps with Windows XP) and see if that helps the issue.
Comments
This issue has been addressed in RB 7.04. If you need information on
upgrading, please contact sales@digital-metaphors.com for more information.
Note that this upgrade is free of charge if you have already purchased a
version of RB 7.x.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
problem is solved ...)
Will install it next week and test.
regards
Andreas
The black image problem still exists in 7.04 I'm using it and can still
reproduce the problem.
The sites that this affects are running the exe across a network. It
therefore appears to be
dependant on speed somehow, as a fast machine running the exe locally will
not reproduce it.
I'd suggest some code to check if the rendering of a page is complete before
sending it to the
printer for the next release.
The changes from 7.03 to 7.04 have reduced the problem from 1 in 2 to about
1 in 10 for our
customers however it is still a significant problem.
Can you tell me if there is a way of getting this working 100%
Regards
Sam Gorman
What type of printer are you printing to? In the past we have found that
certain printers do not handle images as well as others. The fixes made in
ReportBuilder 7.04 greatly reduced the number of "black image" occurances
with our customers but it did not solve the problem for every instance. Be
sure the image you are using has its Transparency property set to False.
You may also want to run your application through a memory checker such as
Sleuth QA or MemCheck to be sure you are not leaking any memory or resources
as this may cause the problem as well.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
We have reports of black printing from an HP 640c, an HP 6122 and
an HP business inkjet 2230.
Transparency is False on all images.
The app worked 100% on Report Builder 5.5 and only failed after a
conversion to Delphi 7 where we had to move to Report Builder 7.
I don't think it is to do with resources, or memory leaks, as I've been
through the code and I can't see any leaks in the area where the printing
occurs and any that previously existed have been fixed. (ie. the Delphi 3
code has leaks)
On previous testing with the source code I could reproduce this using
a break point in one particular part of the code to slow one part of the
threading. 7.04 did not reproduce the same way however it still left me
dubious about the threading. Are you relying on one thread finishing first?
If so it should be checking the thread is complete prior to sending to the
printers canvas. The fact that it does not reproduce with a local exe but
does on sites with slower networks still points towards the threading.
Any ideas
Sam Gorman
There is no multiple threading occurring in ReportBuilder unless you are
using RB Server or Background Printing. The main issue with loading images
before 7.04 was that we were not globally locking the memory used for the
image and it, on occasion, was being re-allocated by Windows elsewhere
before the report had a chance to print. This was fixed in RB 7.04. This
issue had been present in ReportBuilder since its conception so the fact
that it worked in RB 5.5 for your specific case was purely coincedential. I
still must insist that you run your entire application through a memory
checker. The only reason that your images will show up black is due to a
memory or resource leak. Also, you can try printing your report to an
Archive and then printing that archive file. This will separate the image
access from the image printing giving you an idea where the problem lies.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Na not using background printing.
Running the entire application through a memory checker
is not possible, the application is hugh (we are talking a 90Mb
directory with the bulk of that being bpls). I can't see memory
leaks being the problem, possibly overwritting memory yes
but a leak? Maybe if you have used all the resources and memory
but not probable especially with an NT code based OS.
I'll see if I can reproduce the problem with a smaller exe with source.
Sam
As promised I've a test application that can reproduce the problem.
Do you want the source mailed directly to you or in the group?
Be aware the problem was reproduce on an HP DeskJet 850C
and took around 20 prints to get the black images to appear.
Notes on how I reproduced the problem.
I switched to print to a networked HP LaserJet 2200
Series PCL using the PCL driver at one point (probably a
red herring as on site one customer can reproduce the problem
using just to one printer locally on their own machine).
I run the print job from an exe on a network drive to simulate
what the users have on site, though I've no idea if this has any
bearing on the problem.
Regards
Sam Gorman
Please send the example to support@digital-metaphors.com and I'll take a
look at it for you.
--
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
I have too, this problem, but only print with winME
I use RB 9.01
Some Solution ??
Tanks
wQuick
--
This is not a known issue with ReportBuilder 9.01. If possible try printing
your report to a different printer and see if that helps. You may also want
to try installing ReportBuilder to a different machine (Perhaps with Windows
XP) and see if that helps the issue.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
changing the DirectDraw property of the TppImage.
Ken
The problem was really this... It was alone to disactivate. Debtor to
all...
wQuick
--