Linked jpgs in a printed report 1

[fourletr]

I am updating an old 2.6 app to VFP9.0. It is a Church Managment program and it's main screen gives details of the parishioner's family plus an optional photo (jpg) This works perfectly with the jpgs stored in a Blob field. Since the total records is unlikely to be huge (say around 1,000/2,000) and we will suggest users limit their picture resolution to 640 x 480 I do not forsee any problems with file size.
I would like to be able to print a report with the same family pix on it linked to each parishioner's details. This kind of service is available at considerable cost from professional photographers/directory producers. If it could be done in VFP 9.0 as outlined above it would be a fantastic USP and save churches tons of cash.
So far cannot get it to work !!!! Any suggestions

 

[JRB-Bldr]

One way comes quickly to mind, but it seems somewhat 'kludgy'.

Getting the individual's records into a separate data table/cursor for reporting purposes is easy.

I would guess that one part of that individual's data would be the path and file name of the individual's associated picture.

Now you could create a VFP Report Form to 'report' the data and display a picture image. You could build the Report Form to always 'look' for that image file in a fixed location and it would always have the same fixed file name.

The your VFP code could use the individual's data to determine where the specific picture file was located and COPY it to the 'fixed' location and have the file name changed to match what the Report Form was looking for.

Now your 'generic' Report Form has everything it needs to print the report.

SELECT *;
  FROM PersonTable;
  WHERE PersonID = 12345;
  INTO CURSOR ThisPerson

* --- Determine Individual's JPG File Location & Name ---
SELECT ThisPerson
cJPGFile = ALLTRIM(ThisPerson.PictFile)

* --- Copy To 'Standardized' Location With New Filename ---
SET SAFETY OFF
cReportFormImg = "C:\Report\Image\Image.jpg"
COPY FILE (cJPGFile) TO (cReportFormImg)

* --- Run Report ---
SELECT ThisPerson
REPORT FORM MyReport NOCONSOLE TO PRINT

< do whatever >

Good Luck,
JRB-Bldr

 

[TamarGranor]

What's not working? What are you seeing?

Tamar

 

[fourletr]

My problem is finding the correct settings in the VFP report writer. I can't find a way to link the Blob to the OLE picture field. I either get "File does not Exist" or "Invalid filename/Path". I think I'm missing something obvious that my 79 year old brain can't figure out.
everything else is working just fine. Any suggestions would be most gratefully received.

 

[SnyAc]

The most reliable method I have found to link an image to a report record is to create a cursor for the image path or a field in the report cursor that will be populated with the full path to an actual graphic file (JPEG, BMP, whatever). You then add an OLE/image field to the report format and it's control source is a 'File' with the value of the 'File' being the cursor data field that contains the path to the graphic file.

Using general or blob fields to display the actual graphic data has not worked well... so if your data is already contained in a blob field you would have to generate your report by creating a standalone temporary graphic file from the blob data....

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[Dan Freeman]

Do not use Blob fields. Ever.

The only reason it works for you so far is that you've had lucky software installed. Once an application is installed that takes over ownership of JPG data and can't handle the object VFP presents in a blob field, you've lost all of your image data.

Do not use blob fields.

Store your images as separate JPG files and store the path to those files in your database. Your current report needs would be a piece of cake if you'd done that.

 

[Mike Lewis]

I agree with the others that you should avoid Blob fields. Store the images externally, and just keep their path and filenames in your table.

However, if you do decide to use a Blob field, there should be no problem in showing the pictures in a report.

Do this:

1. Add a Picture/OLE Bound control to the report.

2. In its Properties, set "Control Source Type" to "Expression or variable name".

3. Set the control source to the name of the blob field.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

What? Blob fields are not having the problems you describe, dan. You talk of general fields. Blob fields are ideal.

To print Blob field you need an Image Object available at runtime of the report. Eg simply before calling REPORT FORM you create an image object via

Image1 = CreateObject("Image")

In the report ole/picture control in the general tab you set:
1. control source type: check "expression or variable name"
2. control source: [Image1]
3. if source and frame are different sizes "scale contents, retain shape"

In the detail band, which contains the Ole/Image report control, open the properties general tab of that detail band and in "run expresseion", "on entry" enter: EXECSCRIPT("Image1.PictureVal=yourtable.yourblobfieldname")

This is the part, that updates the Imagecontrol to have the image of the current record in it.

And if you don't setup the resizing you probably will not see pictures, they are stored with a resolution in pixels, but - what's often forgotten - also with a pixel resolution in dpi (dots per inch) of the typical 96 dpi a monitor has. Printing with much more dpi the picture is scaled to milimeter sizes and becomes invisible. So step 3 of the properties setting of the Ole/Picture controls ensures you see something at all.

Running the report now takes three steps: opening the table (perhaps also done in the report dataenvironment), creating the variable Image1, then calling Report Form...

Bye, Olaf.

 

[JRB-Bldr]

You might notice above where I said - "I would guess that one part of that individual's data would be the path and file name of the individual's associated picture."

As I implied originally and has been repeated a number of times above by others - NO BLOB/GENERAL FIELDS FOR YOUR IMAGES!

Put the individual's JPG images into their own JPG files and store them in some directory(s) on your system and then put the fully pathed filename into the individual's data record(s) so that they can be located by your application.

The Report Form Image object refers to a FILE, not a data string (which would come from a BLOB field) - that's why you get "File does not Exist" or "Invalid filename/Path".
With the individual's image in their own separate JPG files in a directory, you can do as I suggested or as Mike has suggested above and things will work.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I disagree, blob is not the enemy.

Blob only has the disadvantage of file size, memo bloat, which fourletr already adressed in the initial post. It's true that even in SQL Server, the development goes into seperate storage of such binary files as pictures via filestream storage attribute of blob fields. But if you already have data in blobs and are happy with it, I don't see a reason to make such a step away from it. It may help in making that report easier, but an unknown number of forms needs to be changed then to the use of pictures vs blob fields.

The disadvantages of General fields are worse.

Bye, Olaf.

 

[fourletr]

OK Guys, no squabling !
Blob +Olaf's BRILLIANT solution Works perfectly !!! Why oh why can't we get this sort of information in some sort of Help File/Manual/Wiki ?? I've spent hours "fiddling" around trying to get this to work and now it does. Many Many thanks OLAF you're ACE

 

[Dan Freeman]

Olaf, you are correct. My mind saw blob and immediately translated it to general.

I still won't use blob when the data is native VFP data. When the fpt corrupts, you lose ALL of the image data. I personally have never experienced such corruption but I've had clients who can do it at will.

 

[TamarGranor]

FourLetr - If you've found a solution to this problem that you think should be in the VFP Wiki, add it.

Tamar