Printing images

rbuser

I see that ReportBuilder has support for JPG, BMP, EMF,and WMF. Is there
any way to print a GIF or TIF?

Thanks,
Aaron.

digitalmetaphors

GIF is supported. See the main reports demo #25. You'll have to convert
any non supported image format into one of the supported image formats.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

In article <8EAE82296ACCD311A039005004E0CAC0049908@DMSERVER>,
support@digital-metaphors.com says...

Thanks, Jim. I've looked at that demo, and I've grabbed the full
TGIFImage package, and it all works great with TppImage.

But I don't see how to get it to work with TppDBImage. I've installed
TGifImage, and I've got ppGIF in my uses clause, but when I drop a
TppDBImage on my form, the only choices under GraphicType are Bitmap,
Icon, Jpeg, and Metafile. If I try typing GIF, the Object Inspector
resets this when I leave the field.

Do I need to set this at runtime to GIF, or am I missing something?

Thanks,
Aaron.

digitalmetaphors

When you build your project and the ppGIF unit gets linked in, it registers
the TGIFImage class. That is why it works at runtime but not design time.
If you have RB Pro or Enterprise, launch the designer at runtime and you can
create the report and select GIF as the graphictype. Or, you can set it to
GIF at runtime if you have RB Standard.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

In article <8EAE82296ACCD311A039005004E0CAC004999A@DMSERVER>,
support@digital-metaphors.com says...

Hi Jim,

I can't get this to work for me -- must be missing something stupid.
I've got a Paradox table with a GIF stored in a Blob field. I set up a
Table, DataSource, DBPipeline, and ppReport. The detail band has only a
TppDBImage set to the correct field.

At runtime I to ppDBImage.GraphicType := 'GIF' and ppReport.Print. I
then get an access violation in ntdll.dll and then an EPrintError with
'Cannot generate report'.

I can send you the (tiny) source if you like -- there's not much more
than what I just described. I'm using RB 6 Standard with D5 on Win2K.

Thanks,
Aaron.

digitalmetaphors

Sorry, but looks like we don't currently support GIF image in a DBImage
component.

We traced through code this morning and the reason is that the constructor
isn't called in TGIFImage when the pipeline tries to get the picture. The
create calls skip the TGIFImage create and goes to the TObject create. We
get the TGraphicClass and try to call create on that, whih doesn't work in
this case:

lGraphicClass := GetGraphicClass;
lGraphic := lGraphicClass.Create

We would have to hard code the TGIFImage class into the ppCtrls unit, which
is used in every report. This would make every report have an unnecessarily
larger footprint because it would need to use the GIFImage unit.

The workaround might be to create a custom TppDBGIFImage component that
would hard code the creation of a TGIFImage.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Hi Jim,

Thanks very much for looking into this.


But ppGIF registers TGIFImage as a GraphicClass, so I don't see on the
face of it why this should fail.


Yes, I suppose I could play with that.

Thanks,
Aaron.

rbuser

Hi Aaron,

Maybe it is registered too late, if there is a chance to place the uses of
ppGIF that it is called earlier, I would give it a try.

regards,
Chris Ueberall;

digitalmetaphors

Try this. Have your library path point to Delphi\Lib\Debug and change
RBuilder\Lib to RBldr\Source. Open up ppCtrls.pas and place a break point
in the procedure TppDBImage.LoadPicture;
on the line lGraphic := lGraphicClass.Create; If you check lGraphicClass in
the watch window, it will show GIFImage, however, the GIFImage Create isn't
called, it goes to TObject Create instead. We haven't figured out why
Delphi is doing this.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

In article <8EAE82296ACCD311A039005004E0CAC0049A74@DMSERVER>,
support@digital-metaphors.com says...

Ahh...well, then I feel better. I thought you meant that there was
something obvious in the code that was bypassing TGIFImage.Create, but
if this is something that perplexes you as well, then the cause must be
buried somewhere.

Thanks,
Aaron.