How to import or insert a *.jpg file into a binary memo field 2

[german12]

I have a dbf-file MyPhoto.dbf
with two fields:

MyPicturename = c(200)
MyPicture = memo binary

The picture I would like to have inserted in MyPhoto.dbf is this one with its location:
"F:\Bilder\DCIM\Möve.jpg"

How is the correct insert command to have Myphoto.dbf populated with

the filename "F:\Bilder\DCIM\Möve.jpg" in FIELD Mypicturename
the image in FIELD MyPicture.


My system is VFP 9.0 SP2

Thank you for help

Klaus




Peace worldwide - it starts here...

 

[Mike Lewis]

Hi Klaus,

You need something like this:

SELECT MyPhoto

* go to the record where you want to place the image
* then:

APPEND GENERAL MyPicture FROM  "F:\Bilder\DCIM\Möve.jpg"
REPLACE MyPicturename WITH  "F:\Bilder\DCIM\Möve.jpg"

mIKE

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

APPEND GENERAL would work for a general field, a binary memo field (M NOCPTRAN) or a Blob field just needs to be filled with the file bytes, so

Insert into myphoto (mypicture) values (filetostr("F:\Bilder\DCIM\Möve.jpg"))

Don't go for general fields in most situations, it'll add to the file bytes at the same time you can't easily get the file back from a general field. A good use of them still is as data for a report. But then you can also print an image from a file and just have the filename in your data, so images in the data are unnecessary or have not many applications you can't also do with images themselves.

If you want images embedded, embed them in your EXE, for example as classes based on image and set to a picture file. That pulls the image into the project and embeds it in the EXE, too.

Chriss

 

[german12]

Thank you Mike and Chriss for your advice.
Chriss, I used your hint - and it worked
and access to the photo was also very quick.

For me, this is the first time I've needed images in a file.
As a beginner, I of course first looked at the dbf and saw only cryptic characters in the field for the photos.

Then it occurred to me that for a shape it was, too
an image button there.
I then have this button with the command
thisform.image1.pictureval = m.Mypicture
populated.

Of course the photo on the image button was way too big,
until I decided to set the stretch to Isometric.

These are the tiny steps I have to take when I am
as a beginner wants to learn something.

My questions now are these:
a) Do you also do it with the representation of images in a form
with an image button?
b) Would it be more practical to call up a photo program when you click (I always use Irvan View, good freeware)?

There would be more questions, I'm sure.
But it is probably better not to ask too many questions at once.

I am happy about every answer.

Klaus


Peace worldwide - it starts here...

 

[Chris Miller]

I usually use image controls I set pictures at designtime, not by a button.

What's your goal, display any image a user picks from a dialog? Then look into GetPict(), then set Image.Picture to the filename.

Chriss

 

[german12]

Thank you very much Chris,
This is actually my idea that the user can get image information to a description I will try it with getpict.
It is a program for a pedigree. From a ComboBox with the full name, a description of other data of the person (date of birth, date of death, etc.) should also display the picture of the person. If it is possible, I want to show several pictures at once even after clicking on a family name.eg when the Name ist "Miller" then in Pictures of father,mother,grandfather etc with that Name should bei visible

Klaus

Peace worldwide - it starts here...

 

[Mike Lewis]

Most of the time, I do not use General or Blob fields, especially for storing images, although there are occasions when they are useful. It's usually better to store the image file externally, and store its path and filename in the table (as per your MyPicturename field, Klaus).

You asked about calling up an image program such as Irvan View when the user clicks on the image. That depends on what you want to do with the image. If you just want the user to view it on the screen, the native VFP image control is usually good enough for that. But you might want to give the user more control, such as being able to pan and zoom the image, or possibly even to edit it. In that case, I would use ShellExecute(), passing the image file path and name. That way, the user will invoke whichever program they have which handles JPGs (or whatever other image format you are using).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[german12]

Goal

Peace worldwide - it starts here...

 

[german12]

Thank you Mike for your hints.

I am always happy to see how your explanations, together with the recommendations of the other experts, contribute to an understandable overall picture for solving a problem.

See my goal above as quick draw.

This is my goal:
A combo-box where the family names can be clicked.
After a click all members of that selected familiy are shown with their photos.
By clicking on a photo of a family-member more info of that person should be visible below in a memo-field

I think further manipulation of the picture are in that case not necessary.
If so (zoom e.g.) it would be ok - but not necessarily.

Klaus




Peace worldwide - it starts here...

 

[Chris Miller]

So the images are data about a family. Where do you store the list of family members, does each one have an imagefile field with the filename of the image?
Then you could Select * from family members where familyid=x and add image controls per result record for which you set picture.

You can calculate yourself, how large the memo FPT file will become, if you embed images in a blob field. Blob is the type I'd use for that, and then you can set Pictureval to the blob field.

As you aim for multiple families with possibly many family members each, I don't think storing images within a family member table is the right way. Just store an image name and keep images in the same path as the data, because that folder should be accessible for a user as the data itself should be accessible. If it's all in one folder that should also not have too many image files, so you better have a per family directory, for example. or group images by id ranges in directories with up to about 100 images.

Chriss

 

[Mike Lewis]

Klaus,

Your drawing looks just like me. I don't know how you made it so accurate.

Seriously though, your requirements look perfectly straightforward. I suggest you keep the image files in a separate directory. Don't try to store the images in the DBF. Place several Image controls on your form, one for each family member. In the InteractiveChange of the combo, set each Image control's Picture property to the filename of the relevant image.

Your DBF would also have the "more information" for the family member (in the memo field). You would have an editbox on the form to show that information. In the Image's Click event, you would set the Value property of the edit box to the contents of the memo field.

To resize the image, you could set its Stretch property to 1, and then adjust its Height or its Width properties (not both).

If all the image files are always in the same directory, you would only need to store the filenames, not the paths. Going further, if the image files had the same names as the IDs of the family member, you wouldn't need to store the filename at all.

I think you would probably need two DBFs for this job: one for the family, and one for each family member - with a one-to-many relationship.

It sounds like an interesting application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[german12]

Thank you Mike & Chriss for your prompt answer.

At the moment I have one DBF with the following structure:

(fgroup = a number, where a family belongs to, diedage = the age when a person died = will be a calculated field - and agetoday is the age a died or living person would have today (will also be calculated)

So at the moment I do not want to use memo-fields with infos about born and death-dates.
For other infos (who is who?) is also the field info as a character-field long enough.
If not, then I can switch to memo-fields via replace.

and the *dbf looks like this. (I still search for infos in the families and photos - but I intend to store all the photos in one directory with a filename which includes first name und last name. eg. "johnson boris".jpg

My dbf looks at the moment like this:

I hope that I have not yet forgotten an important field - otherwise please tell me, which you would recommend additionally for that application

Thank you for that idea. I think it would be no problem to split the dbf shown above into individual parts - eg. as a cursor, right?
That is the same with Chriss idea, to store the pictures grouped by family in separate directories.



Best Regards
Klaus


Peace worldwide - it starts here...

 

[Chris Miller]

Well, what Mike addressed was merely normalization of data.

A family is an entity of its own, it's no specific member of the family, but can have any data valid for every member of the family. Surename isn't that anymore, but a family crest.

What you have in fgroup essentially is a foreign key to a families.dbf

You would have such a table, don't you, where does the list of last names for the combobox come from. It should come from families.dbf


Chriss

 

[Mike Lewis]

Klaus, a few comments on your table structure.

First, you say DiedAge and AgeToday are calculated fields. VFP does not have the concept of calculated fields (unlike many other database systems). I think you mean that the program will calculate these values as and when it needs them, for example, when it is printing a report. In general, you should not hold such fields in the table, as they can always be derived from the base fields (Born and Died in this case).

More importantly, you appear not to have a primary key for this table. According to good database design, every table should have a primary key. It could be a simple integer, provided it is unique for the table. It doesn't have to be visible to the user.

If you had a primary key, then you could avoid storing the names of the image files. You could set each image filename to the primary key. So record number 123 would be named 123.jpg.

As we have suggested, you should have two tables: one for the family and one for the individual person. The family table would probably have very little information. The person table would hold the fields such as Nachname, Vorname, Born, etc. It would have its own primary key. And it would have the FGroup field which would links it back to the family table (so FGroup is the foreign key).

None of the above is absolutely essential. But it is good basic database design.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

I would highly recommend against storing images in General fields. Fox has a horrible tendency to corrupt them. Also with VFP's 2gb file limit, you hit it REALLY fast. We abandoned storing images (even static ones) in General fields years ago. It's just as easy to keep them stored in collected directories, and will cause you way way less headaches.

Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Chris Miller]

To give another incentive for normalized database design.

Let's stay with your single table model of data and add a feature to indicate who's married. Lacking a primary key, you'd perhaps use recno. A simple person record could have:
fgroup, firstname, lastname, marriedwithrecno

So if Mr Smith and Mrs Miller exists, they could start as
record 1257: 1,'John','Smith',null
record 1034: 2,'Jane','Miller',null

and married there records would be
record 1257:1,'John','Smith',1034
record 1034:2,'Jane','Miller',1257

Delete a few rows, PACK and you'll get a mess.

So that alone is a good incentive to let every record have a unique identifier that stays as it is by being part of the data iteself.

So lets introduce a person id and you could have
id, fgroup, firstname, lastname, marriedwithid
record 1257:1376,1,'John','Smith',1157
record 1034:1157,2,'Jane','Miller',1376

After a pack the record number can change to whatever, the id still remains as it was when it was introduced.
It also makes it easy to update a record where id=something and ensuring you update the only record you want to update.

This still doesn't address fgroup, but the way to relate two records already has become a better concept.

While it always seems easy enough to have such a virtual foreign key like fgroup and no real family table it points to. You still use fgroup in the concept of a foreign key. Once you know the key fgroup number = key to a family, you don't nned to join to another table, but SELECT * FROM members where fgroup=x gives you all family members. Well, if fgroup will be a real foreign key, that wouldn't change, so why not make this step? And you get the fgroup value from the families.dbf Even if I assume you don't know anything else to store in the familyes.dbf other than a key. Because lastname of members could differ through marriage. It'd still be a major lastname.

You could also emulate family.dbf by doing Select group, min(lastname) group by fgroup. But now what happens if one married member of the family is named 'Miller Smith' and indeed would turn the Smith family to the Miller Smith family. There is no such aggregation function like "most frequent value of the group".

Assume you want to note the marriage of two persons not just on the personal level, but on the family level. You could deduce married families from a self join of persons, selecting the distinct fgroup1, fgroup2 pairs. I'm not even talking about the effect on children's fgroup or the value of fgroup changing for someone taking the others' name. And even if, you'd still also consider yourself as a member of the family you were born into. Which at that point is defined by your parents. And even that could be difficult in a situation of adoption or other reasons the educational parents are not the biological mother and father.

You actually have a new family root level with every pair of parents. They still are part of the greater families of their parents. But that leads far off just for the reason family relationships are even more complex than data relationships.

Chriss

 

[german12]

Chriss

Thank you for the valuable advice about normalized database design.
It shows that the deliberations of a concept take (and should take) more time than the subsequent coding.
I also understand that you also need a unique personnel number for each member of a family and that the affiliation to his/her family must be determined.
As an additional criterion, it occurred to me that a family tree could also show whether a person is a widow or widower.

What would my grandfather say about this, he never had a computer, and yet he - as I found in a very old document - traced the family tree of my oldest brother back to an ancestor who was born in 1632!
All written manually in old german script...but thank god I can still read that.
He even noted if and when someone was baptized.
(see photos).

Thanks again.
Klaus

Peace worldwide - it starts here...

 

[german12]

Mike, thanks also to you.

that's what i meant

You also convince me that it is not necessary to have such data
within a file (although this would of course be possible with "replace all with ...." in the init.
But of course it bloats the file unnecessarily.

I agree.

The idea of ​​using a primary key, which can also be found in the file name of the image file - is very good.
I had taken the name of the person as the filename,
But that causes difficulties again when 2 people (e.g. father and son) have the same name.

I am really amazed at how many new and meaningful considerations are added to an application that at first glance seems to be just simple.


Many thanks.
Klaus.


Peace worldwide - it starts here...

 

[german12]

Scott
I can understand your warning very well.
Thanks a lot for this.

Klaus


Peace worldwide - it starts here...

 

[Scott24x7]

The code isn't difficult. You just store the file location in a memo field. Then you set the source control to that field in the object (picture object), and it will display the file from the directory location. If "encryption" is crucial then you can just encrypt the drive, and it's transparent to the application. This is DEAD easy, and keeps the DBFs small, especially in a 4k world with images of 10mb+ per image. This takes a little to set up, but once done, it's DEAD EASY, and you never have to touch it again.

All it takes is 1 corrupt table, and you'll see why this is a bad idea to store in general field...

Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.