Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Export MEMO fields containing images to BMP files

Status
Not open for further replies.

robeau

MIS
Oct 20, 2000
30
CA
We have an application written in FoxPro 2.6. There are images/pictures stored in MEMO fields that I would like to save to individual bitmap files. I have tried the solution from this link:


However, the BMP file that is created does not show any image. The file has some content in it, because the file size is about 3K.

Are there utilities available that may help with this process?

As the MS article suggests, the offset may be something other than 599. How would I possibly determine what the offset should be?

Thank you for any assistance.
 
I'll start by saying that the design is problematic from the outset.

Image files should NOT be stored directly in Memo Fields.

First - Because it is not really the Image file that goes into the FP/VFP Memo field, but instead it is data from the file which can be used by FP. This is as the reference link above suggests when it says:
FoxPro creates presentation data plus the actual .bmp file data

Second - This can cause Major data table BLOAT due to the size of the Image file data. And this BLOAT can eventually cause application crashes as the data table (and/or its associated files such as the FPT file) approach 2GB in size.

The Image files themselves should have been stored in a file directory and then keep the fully pathed filename in the data table which can then be used by the application to access the Image file.

You might have to do some experimentation to find the actual File data within the Memo field values.
I'd start with a known Image file and then insert it into a FP/VFP data table Memo field in the same manner as your application.
Then I'd use a Hex Editor on the known Image file to examine the header bytes, byte count, etc.
Finally I'd look into the Memo field data and determine where the actual file data resides.
Then you should be able to use that info as a model to export the other Image file data from their respective Memo fields.

Good Luck,
JRB-Bldr
 
Thank you for the reply.

This was a third party application we purchased, so we were not involved in the design, unfortunately. I am trying to contact the original developer to see if he has any insight.

I will explore your suggestions to see if I can figure out the proper offsets.

Bob
 
Just for clarification, you're talking about a general field not a memo field. There IS a difference.
 

No, it is listed as a 'Memo' field type.

It is Foxpro 2.6 for Windows, if that makes a difference.
 
If it's truly a memo field, then you've been given a pig in a poke so far. The article you linked is about extracting data from a general field. The response from jrbldr is about data in a general field.

To get a file out of a memo field:

COPY MEMO (fieldname) TO (filename)

Memo fields are great for hauling around all manner of file, but they're also VERY different from a general field (which doesn't hold a file at all -- they hold objects).
 
Thank you for the reply.

OK, so I tried your suggestion:

COPY MEMO Photo TO C:\TEST4.BMP

But there is no image in the bitmap file, and Paint cannot read the file, saying it's not a valid format.

Have I used the right syntax?
 
There is a very good chance that whoever did this sort of mistake - er, shortcut, read the original image file using low-level I/O, then stuffed it in the memo field possibly even pre-pending or appending the data with some sort of internal or proprietary information.
Most likely, your best chance of getting them back out would be to study header information of a known file and try to match it up with the memo data. Maybe then you could grab the memo data and write it back out raw using more low-level I/O.
Since it's stored in a memo file like that though, which is very uncommon, it will be an iffy struggle at best.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Most likely, your best chance of getting them back out would be to study header information of a known file and try to match it up with the memo data. Maybe then you could grab the memo data and write it back out raw using more low-level I/O.

That's essentially what I said above about investigating the issue through the use of a 'known' image file.

But there is no image in the bitmap file, and Paint cannot read the file, saying it's not a valid format.

Remember: FoxPro creates presentation data plus the actual .bmp file data

With the addition of Foxpro 'presentation' data to the image file data, it is no wonder that data merely copied out of the Memo field into a BMP file will not be a validly formatted BMP Image file.

Time to put on your Sherlock Holmes hat and do it the hard way.

Good Luck,
JRB-Bldr





 
Remember: FoxPro creates presentation data plus the actual .bmp file data

As I said above, this guidance is for a GENERAL field. There is no such tomfoolery with a memo field, which was the subject of the thread. There is no need for presentation data outside of OLE objects.

It is now reported that COPY MEMO didn't throw any errors, which it would if it were called with a non-memo field. (The error is "Field must be a Memo field", intuitively enough.)

This just gets weirder and weirder. The field obviously does not contain a simple bitmap file, and it seems not to be a general field.

 
Let me chime in and go back to square one.

I'll just mention very short, you're entering a legal grey zone, no matter how you extract the images, if they are not put into the table by yourself. Eg extracting UI graphics is not legal in most cases, though it's quite a common practice.

You said:
robeau said:
There are images/pictures stored in MEMO fields that I would like to save to individual bitmap files.

You also said:
robeau said:
it is listed as a 'Memo' field type

You obviously also have Foxpro at hand to see that and to execute code.

The developer may have encoded the data stored in the memo, eg XORed it to protect the pictures from being extracted.
It might also be as simple as being other image formats like ICO, TIF, JPG. There are so many image formats besides BMP. I don't know which of these are supported by fox 2.6 for windows, but I assume also GIF might have a chance or older formats like WMF (windows meta format).

robeau said:
I am trying to contact the original developer to see if he has any insight.
Well, who else should have an insight? Of course he would be able to help.

I assume the images are used by the application itself, so if all else fails you could simply do screenshots.

Bye, Olaf.
 
Olaf, I was also starting to wonder about legalities. One must face that issue with someone else's application anyway, and if they made it difficult the red flag starts waving madly.

Just FYI, though, Fox 2.x was fairly pure about images. It could handle anything as long as it was a bitmap. <g> (No GIF, JPG, etc. support at all.) There were 3rd party libraries for handling other graphics formats (so that could still be in play here), but if it's handled by FPW itself it'll be a BMP.
 
If application shows the data, try google "refox, unfox, etc." to find out what the original developer do.

Nasib
 
is it possible that the blob information of images is stored in the memo field?
and that strings of character will converted to image by a procedure?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top