Image in report prints OK in IDE not in distributable - why? 1

[fourletr]

We have a report with a single image from a blob in a table. This reproduces perfectly in both preview and also when sent to the printer providing we run it in the IDE.

However when we compile it into a distributable .exe application it works fine in preview BUT the printer just prints a large image of the top left portion of the picture and nothing else. Looks like we're missing a DLL or something . Any ideas ? BTW Text only reports working OK


Richard Myers (aka - fourletr)
Burlington - Ontario
Canada

 

[Dan Freeman]

VFP does not have a "blob" data type.

It has general and various versions of memo, but no blob.

If your "blob" is in a general field, redesign and get rid of it. It's absolutely the wrong way to go and this is just the beginning of the problems you'll have.

If that's not what you're doing, you'll have to explain because VFP doesn't have what you say you're using.

 

[Nigel Gomm]

your description of simply showing the top left corner of the image sounds like you need to set the image's properties to "scale contents, retain shape"... but that should be consistent between preview and printer and between ide and .exe.

If it is in a 'general' field then everyone here will say the same as Dan - replace either with a filepath to the image or filetostr() the file into a binary memo field.

General fields, apart from other numerous shortcomings, are reliant on a registered OLE server application drawing the image for you and that can be, err, inconsistent between systems.

hth

nigel

 

[Mike Lewis]

I agree with the others when they say you should avoid embedding the image in the table. Instead, hold the image separately, and store its path in the table.

But doing that won't solve your problem in this case. Although it's good advice, you should ignore it for the moment, and focus on the problem in hand.

When you say that it works in the IDE and not in an executable, are you running the exectuable on the same computer as the IDE? If not, then it's likely that a different application is registered to handle the image type. In that case, it's that application that's at fault.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TamarGranor]

VFP does not have a "blob" data type.

Um, yes, it does in VFP 9.

Tamar

 

[JRB-Bldr]

I'll add my voice in agreement to what the others have said above
you should avoid embedding the image in the table. Instead, hold the image separately, and store its path in the table.


Keep the images in their original form and them include them with your distributed code - perhaps in their own separate directory (maybe "Images") after the Install

Then your application will 'know' where to find them and can use them as needed.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

Um, yes, it does in VFP 9.

oCrapp. I knew that, too. Thanks Tamar.

 

[Mike Lewis]

oCrapp. I knew that, too.

I see you've got a new catch phrase, Dan.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

By the way, french do the best crapp:

http://en.wikipedia.org/wiki/Crêpe

Bye, Olaf.

 

[fourletr]

Thanks for all the suggestions Guys & Gals! In answer to various suggestions heres the scoop.

The images are user installed, in other words our application has the facility for the user to add his/her own images of people, things, documents etc. All in .jpg format. We have tested this very comprehensively and it works just fine providing we run the application in the IDE. However when we generate a distributable application all is well until we try to print. We give the user the option to view their image or print it. The viewing works just fine but as soon as we print it just produces a large image of the top left corner of the picture. We have, of course set the scaling correctly and done all the other things that Olaf kindly suggested way back last year.
The fact that everything works OK when running in the IDE would seem to indicate that we have done everything correctly. It just doesn't work in the distributable. AFAIK we are including all the required .DLLs in the compile script (we're using INNOIDE BTW)Also we are running everything on the same machine for testing purposes. Unfortunately I am away from home (in UK for summer) and only have one machine here. Normally I would test on a seperate machine that was "clean" in other words had no VFP installed. My partner, back in Canada, is currently testing on such a computer and I'm awaiting his results.


Richard Myers (aka - fourletr)
Burlington - Ontario
Canada

 

[Mike Lewis]

Richard,

You are obviously testing this in a systematic way, and have correctly focused on the scenario where the problem occurs.

One other variable to consider is the actual printer. It's just possible (though unlikely) that the problem is caused by the printer driver. Have you tried printing to a different printer or driver?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[fourletr]

Hi Mike:

Again, being away from "home base" I only have the one printer. However I'm not sure that the printer driver would affect anything since it DOES print perfectly from the IDE.

BTW you can download a demo copy from our website

http://www.sjsa.com.

Go to PRODUCts and select TAM2000/download demo.

This probably wont help you much except conceptually.

Thanks for your help ... so far !

Richard Myers (aka - fourletr)
Burlington - Ontario
Canada

 

[Olaf Doschke]

Did you ionstall the ReportOutput.app? If not, that may be the difference between your IDE testing and the final exe.

In fact ewverything you test in the IDE is running via vfp9.exe, while a compiled exe uses vfp9r.dll mainly, so behaviour can differ in everything. Especially in this case, as there are two report engines reportbehaviour 80 and 90.

Also in general such environmental settings as reportbehavior and sqlengine may default to other settings, if running the exe.

The default for reportbehavior in any exe seems to be 80, even if your default IDE setting is 90. I just compiled "? SET("Reportbehavior") / Wait" to an exe and the exe shows 80. Blob support with the legacy report engine may not be good enough. They abviously added blob support overall. Another suspicion I have is the report interprets a very low dpi setting with your images and this leads to very large prints. Printer devices have a rather high dpi rate compared to screens, so if the picture embedded dpi rate is good for the screen, a preview is fine and the print is coming out much too huge.

I think this really points to a bug, as you don't get that effect with fonts at all, the report engine makes a difference between the devices for preview and print.

Test if SET REPORTBEHAVIOR 90 in your star.prg/main.prg would help.

Bye, Olaf.

 

[fourletr]

Wow ! Olaf you deserve a medal! Adding "REPORT BEHAVIOUR 90" to our MAIN.prg plus including ReportOutput.app in the compile script files. It works like a dream! Had to HIDE the print/choice window to prevent all the commands being echoed to the screen. SET TALK OFF didn't seem to do the trick. However it now works just fine. Only problem is my UK printer has died! Dried up ink after standing idle for 7 months. But it at least worked long enough to prove that we had cracked it.

Again many thanks for your speedy and wise assistance.


Richard Myers (aka - fourletr)
Burlington - Ontario
Canada

 

[Olaf Doschke]

Had to HIDE the print/choice window to prevent all the commands being echoed to the screen. SET TALK OFF didn't seem to do the trick.

That's a known issue, see thread184-1640637

Unfortunately it was unresolved.

You still may try the newest version of reportoutput from VFPX at codeplex and try allowoutput = .f. in _screen and/or your form.

And you may try to set _reportoutput to the app file or even to "", not using it, but still using reportbehavior 90. Give some combinations a try.

Bye, Olaf.

 

[Olaf Doschke]

Sorry,

that reference to another thread should be [link tek-tips.com/viewthread.cfm?qid=1640637]Visual Foxpro HTML report listener: how to get rid of messages[/url]

TGML processing seems to be lost with the relaunch here. Doesn't help much anyway. Lots of discussion with no solution.

Bye, Olaf.

 

[Koen Piller]

Hi,

To solve the bug of echo in Reportlistner with VFP9SP2, Cathy has found a solution.
Please read her blog at

http://cathypountney.blogspot.com/2009/04/set-talk-appears-to-be-on-when-running.html

Regards,

Jockey(2)

 

[Olaf Doschke]

Modify the fxListener class of the _ReportListener class library and change the code in the LoadReport method. Simply move This.setFRXDataSessionEnvironment() so it comes before This.createHelperObjects() and the problem is solved.

That only applies, if using reportlisteners.

Bye, Olaf.

 

[Olaf Doschke]

OK, looking into

http://msdn.microsoft.com/en-us/library/ms973093(v=vs.80).aspx

You are now automatically using the ffc reportlisteners, even just using plain old REPORT FORM...

Specifies that when Visual FoxPro executes a command that requires report rendering, it will use the application specified by the _REPORTOUTPUT system variable to obtain an instance of a ReportListener class to perform the rendering.

So this fix really will help.

Bye, Olaf.