how to get a reference to pictures stored on disk? 1

[Nifrabar]

Hi!,

My Q:
I am having a map on disk holding lots of jpg-files.
Now I want to organise things using VFP, putting details of the JPG's into a table.
Than, when browsing to the table I like to view the contents of the JPG.
I found a way using general field but experienced that (watching the size of the vfp-file) that the jpg was kind of 'copied' into the vfp-table.

APPEND GENERAL foto FROM 'C:\pictures\k.ooms.jpg'

Any idea what;s a better way?

-Bart

 

[alvechurchdata]

It's usually better to store the names of the jpgs in the table. You can then create a form with an Image control and set the Picture property of the image as you move through the table.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Scott24x7]

Nifrabar,
I used to use what you are doing all the time, but those table are SO susceptible to OLE corruption, and honestly after 3 years of working with them I was never able to determine what would cause them so frequently. I could browse a table, make no changes to the file, and then browse it another day, and I'd have OLE corruptions on my images...
SO, I started doing this instead:
1) Create an Images (or whatever name you want) directory within your application directory structure.
2) Place all Images that are going to be used by your program into that directory.
3) Place the directory name and file name into a MEMO file. I decided on Memo's because of the unpredictable nature of file names, and did not want to have to rely on them being a specific length.
4) On the FORM or REPORT that you use, use the PICTURE object, instead of an OLE bound control.
5) Set the reference programmatically in your form to This.Picture = (<Table>.<MemoFieldName>). For a REPORT, using the "Picture/Ole Control" object, set the 3rd radio button (Expression or variable) and in the control source put in the name of the Memo Field.

This is fast, clean, and independent of needing to muck with OLE control programs that have to be attached with the APPEND GENERAL. As long as you keep it contained within your application's directory, and use just that part of the directory (you can even fairly safely hard-code this one...) saving just that part of the path, you can easily move your application from drive to drive, directory to directory without the need to update the path element of the picture files. It will reduce/remove a significant headache for you, especially if you have a table that needs frequent changes to OLE objects.

In the very least, if you are going to update the OLE object itself, DON'T do it by replacing the existing data. I found HEAPS of corruption problems with this. Better to make a new row, and delete the existing record. I was able to reduce my OLE corruption by about 80% when doing this, but still was too frequent for commercial use, hence my eventual migration to Memo fields. I have had zero issues with it in terms of performance, and in fact have noticed that on some machines it looks much better than the OLE versions do.

The Down Side: You have to expose your image files to the system... so not so much control over them. The OLE method works for like a business Logo that's used throughout the system or something, and is fairly static, but I don't use that method for anything else.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Nifrabar]

Geoff and Scott,

As far as I can see you both do suggest in principle same option.
So I will follow that approach.
I don't have to much experience with OLE this way but I understand it's better to keep away from it here.
Thanks for yr advices!

-Bart

 

[KenWMurphy]

There is one proviso though - if you have over 1024 image files in a single directory, you may find that windows indexing no longer works for that dir - it will slow down considerably.

The solution to this is to create a directory structure rather than a single directory. You could do something like Images\ProductType1\ProductCat1\Image1.jpg.

If you must store images in a table, I find that the best way to handle it is to store FILETOSTR([Path2\MyImage.jpg]) to a memo field. When you want to retrieve it, use STRTOFILE().

kEN