I too am a novice and have an FM DB of 8000 pix.

I have thumb nail size pix which I wish to load into a bigger frame to view (sort of basic html action) in the same layout.

I created a spcific containter & wrote a copy & paste into a container script but when I click elsewhere FM asks if you want to save the revision. As I do not, I tried to find a script that automatically says no cannot not find one.

I presume there is a easy way of doing this, but what?

I too am a novice and have an FM DB of 8000 pix.

I have thumb nail size pix which I wish to load into a bigger frame to view (sort of basic html action) in the same layout.

I created a spcific containter & wrote a copy & paste into a container script but when I click elsewhere FM asks if you want to save the revision. As I do not, I tried to find a script that automatically says no cannot not find one.

I presume there is a easy way of doing this, but what?

I too am a novice and have an FM DB of 8000 pix.

I have thumb nail size pix which I wish to load into a bigger frame to view (sort of basic html action) in the same layout.

I created a spcific containter & wrote a copy & paste into a container script but when I click elsewhere FM asks if you want to save the revision. As I do not, I tried to find a script that automatically says no cannot not find one.

I presume there is a easy way of doing this, but what?

No need to copy and paste.

Make another layout with the container field on it, only resize the filed so it's as big as you need. Then switch layouts.

No need to copy and paste.

Make another layout with the container field on it, only resize the filed so it's as big as you need. Then switch layouts.

No need to copy and paste.

Make another layout with the container field on it, only resize the filed so it's as big as you need. Then switch layouts.

What I want is that the thumbnail loads into generic container that is just bigger in the same layout, as if you were on a web page.

Thanks

PS I love your the photo. Very cool. "popular culture, popular culture!"

What I want is that the thumbnail loads into generic container that is just bigger in the same layout, as if you were on a web page.

Thanks

PS I love your the photo. Very cool. "popular culture, popular culture!"

What I want is that the thumbnail loads into generic container that is just bigger in the same layout, as if you were on a web page.

Thanks

PS I love your the photo. Very cool. "popular culture, popular culture!"

>I have thumb nail size pix which I wish to load into a bigger frame to view

When talking about images it's important to get everything straight. Your statement is ambiguous. If it's a "thumbnail size pix" then it cannot be "bigger," unless you are just using the "Reduce" Graphics option to make the big picture look like a thumbnail.

The above will work, but it has the (great) disadvantage that each "thumbnail" will take just as long to load as the full sized version. Because it is the full size version, just squished.

The normal way to do this (on the web or anywhere) is to have a real thumbnail image AND a full-size image; that's 2 images. Is that what you actually have?

>I have thumb nail size pix which I wish to load into a bigger frame to view

When talking about images it's important to get everything straight. Your statement is ambiguous. If it's a "thumbnail size pix" then it cannot be "bigger," unless you are just using the "Reduce" Graphics option to make the big picture look like a thumbnail.

The above will work, but it has the (great) disadvantage that each "thumbnail" will take just as long to load as the full sized version. Because it is the full size version, just squished.

The normal way to do this (on the web or anywhere) is to have a real thumbnail image AND a full-size image; that's 2 images. Is that what you actually have?

>I have thumb nail size pix which I wish to load into a bigger frame to view

When talking about images it's important to get everything straight. Your statement is ambiguous. If it's a "thumbnail size pix" then it cannot be "bigger," unless you are just using the "Reduce" Graphics option to make the big picture look like a thumbnail.

The above will work, but it has the (great) disadvantage that each "thumbnail" will take just as long to load as the full sized version. Because it is the full size version, just squished.

The normal way to do this (on the web or anywhere) is to have a real thumbnail image AND a full-size image; that's 2 images. Is that what you actually have?

No, these are squished images that way about 50k, so good enough for viewing large

No, these are squished images that way about 50k, so good enough for viewing large

No, these are squished images that way about 50k, so good enough for viewing large

OK, this is a modified version of an example file I built for this. Usually I have the 2 files, with a "real" thumbnail. But this example is using the real picture reduced as the thumbnail. Same principle for switching via the portal however.

Here is something I wrote about the original file:

This is an example of a way to show multiple thumbnails* & their full-size image for a record. The record could be anything with associated images. In this file the images are fully embedded, for portability; but it would also work with referenced or calculated* images. The thumbnails would likely be embedded in any case. But the focus of this file is simply how to "flip" the big image by clicking the thumbnail.

Each pair of thumbnail

OK, this is a modified version of an example file I built for this. Usually I have the 2 files, with a "real" thumbnail. But this example is using the real picture reduced as the thumbnail. Same principle for switching via the portal however.

Here is something I wrote about the original file:

This is an example of a way to show multiple thumbnails* & their full-size image for a record. The record could be anything with associated images. In this file the images are fully embedded, for portability; but it would also work with referenced or calculated* images. The thumbnails would likely be embedded in any case. But the focus of this file is simply how to "flip" the big image by clicking the thumbnail.

Each pair of thumbnail

OK, this is a modified version of an example file I built for this. Usually I have the 2 files, with a "real" thumbnail. But this example is using the real picture reduced as the thumbnail. Same principle for switching via the portal however.

Here is something I wrote about the original file:

This is an example of a way to show multiple thumbnails* & their full-size image for a record. The record could be anything with associated images. In this file the images are fully embedded, for portability; but it would also work with referenced or calculated* images. The thumbnails would likely be embedded in any case. But the focus of this file is simply how to "flip" the big image by clicking the thumbnail.

Each pair of thumbnail

ThumbsImages2.zip

Thank you very much. It is very impressive and frankly I don't get it. Sadly I am not sure that my DB has been conceived correctly. I have taken the liberty of attaching a clone with a couple of picts. Each "page has its only id, but not each picture. Is it poss to do your miracle in my configeration? Thank you in advance

Christopher

Name: admin

There is no password

Thank you very much. It is very impressive and frankly I don't get it. Sadly I am not sure that my DB has been conceived correctly. I have taken the liberty of attaching a clone with a couple of picts. Each "page has its only id, but not each picture. Is it poss to do your miracle in my configeration? Thank you in advance

Christopher

Name: admin

There is no password

Thank you very much. It is very impressive and frankly I don't get it. Sadly I am not sure that my DB has been conceived correctly. I have taken the liberty of attaching a clone with a couple of picts. Each "page has its only id, but not each picture. Is it poss to do your miracle in my configeration? Thank you in advance

Christopher

Name: admin

There is no password

CloneClone.fp7.zip

OK. Whenever there are multiple items for a record, it usually means another table is needed. Never do Photo1, photo2, photo3,... Just create another table, with 1 container field.

I redid the layout a bit. It seems to me that you'd want more space for the big photo, with the portal going down the side. It could also be done as you did, in blocks. To do that you'd do 3 portals, same relationship, 1st portal starts with Row 1, shows 2. 2nd Portal starts at Row 3, shows 2, etc.. Then you'd have more room for other data. I didn't really know.

I duplicated the layout, and the relationship, for data (photo) entry. The entry layout has a duplicate relationship, but with "allow creation of related records" ON. So you can use Insert Picture into the 1st blank row to add photos, and also their description.

The main layout has all data entry off. Because you can't Insert into a portal and click on it to run a script at the same time (actually you can, if you check with a script; but it seemed you wanted to secure that layout; and it's simpler). You could also go to the Image table to enter the photos. There's more than one way to do all this, so let us know.

They are linked by the ID of the main table. I don't know if you get this, but you need to, because relationships between tables is what FileMaker is all about.

I don't know what those other container fields are, so can't judge what/where they go.

OK. Whenever there are multiple items for a record, it usually means another table is needed. Never do Photo1, photo2, photo3,... Just create another table, with 1 container field.

I redid the layout a bit. It seems to me that you'd want more space for the big photo, with the portal going down the side. It could also be done as you did, in blocks. To do that you'd do 3 portals, same relationship, 1st portal starts with Row 1, shows 2. 2nd Portal starts at Row 3, shows 2, etc.. Then you'd have more room for other data. I didn't really know.

I duplicated the layout, and the relationship, for data (photo) entry. The entry layout has a duplicate relationship, but with "allow creation of related records" ON. So you can use Insert Picture into the 1st blank row to add photos, and also their description.

The main layout has all data entry off. Because you can't Insert into a portal and click on it to run a script at the same time (actually you can, if you check with a script; but it seemed you wanted to secure that layout; and it's simpler). You could also go to the Image table to enter the photos. There's more than one way to do all this, so let us know.

They are linked by the ID of the main table. I don't know if you get this, but you need to, because relationships between tables is what FileMaker is all about.

I don't know what those other container fields are, so can't judge what/where they go.

OK. Whenever there are multiple items for a record, it usually means another table is needed. Never do Photo1, photo2, photo3,... Just create another table, with 1 container field.

I redid the layout a bit. It seems to me that you'd want more space for the big photo, with the portal going down the side. It could also be done as you did, in blocks. To do that you'd do 3 portals, same relationship, 1st portal starts with Row 1, shows 2. 2nd Portal starts at Row 3, shows 2, etc.. Then you'd have more room for other data. I didn't really know.

I duplicated the layout, and the relationship, for data (photo) entry. The entry layout has a duplicate relationship, but with "allow creation of related records" ON. So you can use Insert Picture into the 1st blank row to add photos, and also their description.

The main layout has all data entry off. Because you can't Insert into a portal and click on it to run a script at the same time (actually you can, if you check with a script; but it seemed you wanted to secure that layout; and it's simpler). You could also go to the Image table to enter the photos. There's more than one way to do all this, so let us know.

They are linked by the ID of the main table. I don't know if you get this, but you need to, because relationships between tables is what FileMaker is all about.

I don't know what those other container fields are, so can't judge what/where they go.

ImagesClone.zip

This is the same thing, but more like your first file. Notice how the portal rows are done, with only 2 in each; same relationship.

This is the same thing, but more like your first file. Notice how the portal rows are done, with only 2 in each; same relationship.

This is the same thing, but more like your first file. Notice how the portal rows are done, with only 2 in each; same relationship.

Images3.zip

Thank you very much. I do not know how to thank you for your time.

There is one thing that I need to clarify.

As I will "exploit" your precious work, how can I easily migrate from my "rubbish" structure to yours? Can I just change the field names in the database or do I have to reimport all the pix I have?

If so, what is the clever way of "extracting" the pix elements so that they can be reimported?

Thank you again

Thank you very much. I do not know how to thank you for your time.

There is one thing that I need to clarify.

As I will "exploit" your precious work, how can I easily migrate from my "rubbish" structure to yours? Can I just change the field names in the database or do I have to reimport all the pix I have?

If so, what is the clever way of "extracting" the pix elements so that they can be reimported?

Thank you again

Thank you very much. I do not know how to thank you for your time.

There is one thing that I need to clarify.

As I will "exploit" your precious work, how can I easily migrate from my "rubbish" structure to yours? Can I just change the field names in the database or do I have to reimport all the pix I have?

If so, what is the clever way of "extracting" the pix elements so that they can be reimported?

Thank you again

You will have to do multiple Imports from the old structure to the new, into the Images table. No need to "extract" to external files.

If done in the same file, it's an import from one table to another. Just choose the right table occurrences in the Import dialog and line up the fields (as below). Steps, in order:

Create the Images table and its fields.

Create those Table Occurrences (TO) on the Relationship Graph, exactly as in my file.

Create blank layouts, for the correct TO (in the New Layout dialog).

Copy/paste the layouts into your file. Check the portal(s) and fields.

Show all records in the main table.

Go to a plain Images table layout.

The first Import you'll line up:

ID --> PM_ID

Photo2 --> Image

In the next dialog,

[x] Allow auto-enter calculations

(for the Images SerialID to populate)

The next time you'll line up:

ID --> PM_ID

Photo3 --> Image

Repeat until you've imported all Photo fields with pictures in them from the other table.

When you have, delete all the Photo fields in that table.

Save a Copy As Compressed

Throw away the original, use the compressed one (remove " Copy" from the name).

You will have to do multiple Imports from the old structure to the new, into the Images table. No need to "extract" to external files.

If done in the same file, it's an import from one table to another. Just choose the right table occurrences in the Import dialog and line up the fields (as below). Steps, in order:

Create the Images table and its fields.

Create those Table Occurrences (TO) on the Relationship Graph, exactly as in my file.

Create blank layouts, for the correct TO (in the New Layout dialog).

Copy/paste the layouts into your file. Check the portal(s) and fields.

Show all records in the main table.

Go to a plain Images table layout.

The first Import you'll line up:

ID --> PM_ID

Photo2 --> Image

In the next dialog,

[x] Allow auto-enter calculations

(for the Images SerialID to populate)

The next time you'll line up:

ID --> PM_ID

Photo3 --> Image

Repeat until you've imported all Photo fields with pictures in them from the other table.

When you have, delete all the Photo fields in that table.

Save a Copy As Compressed

Throw away the original, use the compressed one (remove " Copy" from the name).

You will have to do multiple Imports from the old structure to the new, into the Images table. No need to "extract" to external files.

If done in the same file, it's an import from one table to another. Just choose the right table occurrences in the Import dialog and line up the fields (as below). Steps, in order:

Create the Images table and its fields.

Create those Table Occurrences (TO) on the Relationship Graph, exactly as in my file.

Create blank layouts, for the correct TO (in the New Layout dialog).

Copy/paste the layouts into your file. Check the portal(s) and fields.

Show all records in the main table.

Go to a plain Images table layout.

The first Import you'll line up:

ID --> PM_ID

Photo2 --> Image

In the next dialog,

[x] Allow auto-enter calculations

(for the Images SerialID to populate)

The next time you'll line up:

ID --> PM_ID

Photo3 --> Image

Repeat until you've imported all Photo fields with pictures in them from the other table.

When you have, delete all the Photo fields in that table.

Save a Copy As Compressed

Throw away the original, use the compressed one (remove " Copy" from the name).

why compress the file? doe sthis affect the web publishing?

why compress the file? doe sthis affect the web publishing?

why compress the file? doe sthis affect the web publishing?

No. This is a FileMaker operation. In 7 it now says: Save a Copy As, then "Compacted copy (smaller)". Sorry for the confusion. I never use it myself anymore, because I have FileMaker Developer 7, which has a special "File Maintenance" command, which does it to the current file without going through this 3 step procedure.

Saving as compacted goes through the file, removing any unused space, which you have a fair amount of after you delete a bunch of container objects. Filemaker does a fair job of this anyway, when you close the file. But the above does it better.

Then you throw away the original file and use the " Copy" one, after removing that extra suffix.

[be careful. Do not Save a Copy as " Clone," then throw away the original. Clone is a empty file.]

No. This is a FileMaker operation. In 7 it now says: Save a Copy As, then "Compacted copy (smaller)". Sorry for the confusion. I never use it myself anymore, because I have FileMaker Developer 7, which has a special "File Maintenance" command, which does it to the current file without going through this 3 step procedure.

Saving as compacted goes through the file, removing any unused space, which you have a fair amount of after you delete a bunch of container objects. Filemaker does a fair job of this anyway, when you close the file. But the above does it better.

Then you throw away the original file and use the " Copy" one, after removing that extra suffix.

[be careful. Do not Save a Copy as " Clone," then throw away the original. Clone is a empty file.]

No. This is a FileMaker operation. In 7 it now says: Save a Copy As, then "Compacted copy (smaller)". Sorry for the confusion. I never use it myself anymore, because I have FileMaker Developer 7, which has a special "File Maintenance" command, which does it to the current file without going through this 3 step procedure.

Saving as compacted goes through the file, removing any unused space, which you have a fair amount of after you delete a bunch of container objects. Filemaker does a fair job of this anyway, when you close the file. But the above does it better.

Then you throw away the original file and use the " Copy" one, after removing that extra suffix.

[be careful. Do not Save a Copy as " Clone," then throw away the original. Clone is a empty file.]

Well, after some discovering ... it seems to works a treat. Thank you very much. I don't understand fully how it works but I am looking in to it.

Lastly, what is the "PhotoID" & "Ouverture" fields do & what do I link them to?

Thank you

Well, after some discovering ... it seems to works a treat. Thank you very much. I don't understand fully how it works but I am looking in to it.

Lastly, what is the "PhotoID" & "Ouverture" fields do & what do I link them to?

Thank you

Lastly, I find that it does not work on web publishing via the net. Is this normal?

Lastly, I find that it does not work on web publishing via the net. Is this normal?

Last of the lasts, my orginal file was 350megs. Now it is upto 450megs. Is there any reason?

Also, I do not understand the

"When you have, delete all the Photo fields in that table." instruction. I can't find where all the photo fields are in the table? Is this emprty info that when removed reduces the file size?

Last of the lasts, my orginal file was 350megs. Now it is upto 450megs. Is there any reason?

Also, I do not understand the

"When you have, delete all the Photo fields in that table." instruction. I can't find where all the photo fields are in the table? Is this emprty info that when removed reduces the file size?

PhotoID is the field we are setting with a script, in order to show the photo in the big frame.

"Ouverture", I have no idea. It's your field.

Originally you had the photos in the main table, in fields Photo1, Photo2, etc.. I said Import them into another table, into 1 field, Image.

After importing the original photos are still in the original table. If the imports were successful, you should be able to delete those fields (Photo1, Photo2, etc.). Be sure to have backups in case something goes wrong.

I added the "Save a Copy As, Compacted" procedure in order to slim the file down. It's optional. That may be the 450 to 350 difference; that is kind of a large gap, but I've seen large savings with that procedure.

I don't see why it wouldn't work with IWP on the web, as long as the images are embedded, but I haven't tried it.

PhotoID is the field we are setting with a script, in order to show the photo in the big frame.

"Ouverture", I have no idea. It's your field.

Originally you had the photos in the main table, in fields Photo1, Photo2, etc.. I said Import them into another table, into 1 field, Image.

After importing the original photos are still in the original table. If the imports were successful, you should be able to delete those fields (Photo1, Photo2, etc.). Be sure to have backups in case something goes wrong.

I added the "Save a Copy As, Compacted" procedure in order to slim the file down. It's optional. That may be the 450 to 350 difference; that is kind of a large gap, but I've seen large savings with that procedure.

I don't see why it wouldn't work with IWP on the web, as long as the images are embedded, but I haven't tried it.

Ok, I just took your DB and importted into the image field each of the 20 photo fields from the old one. I presume that it amounts to the same thing. I always say, if it ain't broke, don't fix it.

I will now try and really understand the logic of all this.

Thank you for your extreme generosity

Ok, I just took your DB and importted into the image field each of the 20 photo fields from the old one. I presume that it amounts to the same thing. I always say, if it ain't broke, don't fix it.

I will now try and really understand the logic of all this.

Thank you for your extreme generosity