Create new container field?

[Frink1234]

Is it possible to write a script to create a new container field in a selected record? I want the user to be able to create as many container fields to import pictures for a selected record on an as needed basis.

[Fenton]

This is not how to do it. You cannot, and should not create a field with a script. Not even possible.

Use a related table. Then they can import as many as they want, into just 1 field. Show them in a portal, with allow creation of related records, or some other mechanism for new images.

A useful layout is to show a portal of small thumbnails on the side, with 1 large container. Clicking on a thumbnail sets a field in the parent table to that portal row's ID. Then the large related container (based on both IDs) shows the picture at full size.

Or (even easier) pop up a new window with the full size picture. As long as they close it they should be OK. It would work much like the web. That would let you have many thumbnails; fill the screen if you need to.

The trick is to make viewing the many images work well AND make adding the many images easy. Since multiple large images will not all fit on the screen at once, you need some kind of mechanism to add them, and something to show them.

Do they have or want thumbnails? Or is just big images?

[Frink1234]

The way I currently have the layout is to allow a total of 6 pictures per page (2 columns 3 rows) and then I have Zoom In and Out buttons to enlarge the images. Your idea is much nicer (and more sophisticated) to have thumbnails displayed. Can the portal be made to display a grid of photos, say 5 columns 10 rows? I really like your idea and any elaboration you can offer is appreciated.

[David Holmberg]

One portal can only show 1 column (but unlimited number of rows). But you can have many portals on the same layout and use different relationships, with a little work you can get the "column effect"

[Fenton]

In 7 you do not need separate relationships to show multiple columns of the same portal. You can specify which row to start with and end with, very convenient for these situations. So the 1st column is rows 1-10, the next 11-20, etc., same relationship, same fields. You could do a "contact sheet" kind of layout with 1 relationship.

[Barbecue]

In 7 you do not need separate relationships to show multiple columns of the same portal. You can specify which row to start with and end with, very convenient for these situations. So the 1st column is rows 1-10, the next 11-20, etc., same relationship, same fields. You could do a "contact sheet" kind of layout with 1 relationship.

Kewl!

[Frink1234]

I'm having difficulty with the step of getting the thumbnail images to populate the portal rows. I have created related tables and I can get an image to appear in one portal row but each time I go to insert a new image in the related table it replaces the image instead of adding it to the next portal row. What am I missing?

[Fenton]

Well, you have to insert the image into a blank portal row. To get a blank portal row you need to have "Allow creation of related records" turned on for portal's relationship (on the child table's side). Which means you have 2 tables, with a relationship on the parent's unique ID, to a similar, but non-unique foreign key in the child table.

As I said (vaguely) earlier, the problem is that only 1 full-size image can show at a time, whereas multiple thumbnail images can show. It makes it somewhat tricky to add a new full-size related image. You can put the thumbnail in first, to create the related record, then put the big one in the blank box. The thumbnail and big image are in the same related record.

Alternatively you can just go to the related table and add/import the images directly.

I have a several example files doing something like this. But all of them use AppleScript for one thing or another. It is not that you cannot (with discipline) use just FileMaker alone for this; but it's easier and more powerful to add another tool to the mix. There are several different possible procedures for adding images. It sounds as if you're doing it manually, which is fine (but tedious).

One can also Import entire folders of images at once, with the Import Folder command. FileMaker can create the thumbnails (if desired), and bring in the file name, and path. It can also use the Update Matching Records option to match existed records (though this could be slow on large data sets).

In 7 you can also reference images simply by entering (or calculating) their relative file path to the database file. There are a few considerations however, in all cases, such as "stand-alone machine or network?" We could better advise which method(s) you might want to use if we knew the environment and eventual use of the images and files.

If you still have problems you might want to upload a clone of your file.

[Frink1234]

I'm pretty sure I'm going to just import the images manually into the related table. I would like to be able to display 2 large images side-by-side as a "before" and "after" comparison. Can I create 2 separate import fields in the related table (Before_Image and After_Image) and use 2 separate portals for the thumbnails and 2 large image fields for display? Tell me if I'm on the right track with this:

Main Screen

-ID_Field

-Thumbnails_Portal_Before

-Thumbnails_Portal_After

-Large_Image_Before

-Large_Image_After

Import Images Table

-ID_Field

-Before_Image

-After_Image

Do I make the Before and After fields in the Import Images Table global?

Anything else I'm missing here?

[Fenton]

We're getting there. But there's a couple basic misconceptions. First, the images don't go into global fields; a global field has only 1 value for its entire table.

Second, a portal is just a special kind of "mini-window within the main window" to look at related data, each record as a row. It is not data itself. It has related fields inside, which have data. Probably you know this. It's hard to talk about "objects on the layout" and "tables, fields and data as they really exists in the database structure" at the same time; there is considerable overlap, but they're not exactly the same thing.

Here is one way to do it:

Main Screen

-ID_Field <-- auto-enter serial ID, unique in any case

-Thumbnails_Portal_Before <--portal ( ID to MainID ), show Before thumbnail

-Thumbnails_Portal_After <-- porta ( ID to MainID ), show After thumbnail

_ImageID_Before <-- field, set by clicking a portal row; set to the primary ID of the child table

_ImageID_After <-- field, set by clicking a portal row; set to the primary ID of the child table

-Large_Image_Before <-- as a related field only. Relationship: ImageID (above) to ImageID, Before Image

-Large_Image_After <-- ditto (relationship: ImageID to ImageID)

(I'm using a regular field, not a global, for the temporary ImageID in the Main table. If it was a global, the wrong image would show in other records.)

Import Images Table

Main ID_Field <-- foreign key

Image ID <-- auto-enter serial ID

-Before_Image

-After_Image

Thumbnail_Before <-- these have to exist, in Images table

Thumbnail_After <-- ditto

One possible problem I see is how to import the folders and get the Before and After images into the correct fields. You can only import into 1 image field at a time. So 2 Image fields means 2 Imports.

If you have a folder hierarchy like:

Clients/Client/Photos/Before/

Clients/Client/Photos/After/

How can you only import either Before or After images when importing for all Clients? Maybe you only import for 1 client at a time. In that case the above would be fine; still 2 imports, but manageable.

If it was:

Photos/Before/Clients/Client/

Photos/After/Clients/Client/

then you could. But that's kind of a non-intuitive hierarchy.

Another method would be to have 2 tables for the Images, BeforeImages and AfterImages. Since you're using separate portals, main images, etc., you just target the relevant table. But this would have more or less the same problem as above. Hard to separate imports.

A 3rd method would be to have 1 table, with only 1 Image field per record; so 2 records for 1 Before and 1 After. Then it's just 1 Import. I think that's what I'd do, if the folder structure is consistent and images are batch imported (maybe not necessary in your case however).

Then parse the Before and After out of the filepath, to create a "Type" field for each image. This could be used in multiple criteria relationships, to keep them separate. Either folder structure works (so you could use the 1st, which is most logical: Clients/Client/Photos/Before/ ).

The relationships are a little more complicated, but not much. You could also just reference the pictures via a calculation, using:

"image:relative folder path/file name"

There is more than 1 way to do images. It depends on your environment and your data entry procedure which structure and method to use; and on your platform which external tools you might want to use as helpers (if any).

[Frink1234]

Thank you for the very detailed answer. You have helped this newbie greatly.

Now that I've got the thumbnails displayed in a portal, what type of script will allow me to click on one of the thumbnails and show it full-size?

[Frink1234]

The only way I figured-out is to enter (put the cursor) in the field that contains the thumbnail then click a button that runs a cut and paste script to a layout with a large global container field. I know there must be a more elegant solution that does away with me physically putting the cursor in the field. When I try to use the "Go To Portal Row" command it doesn't work (although I imagine I'm just not working it right).

[Frink1234]

I know the answer is in what you said before in this paragraph:

"A useful layout is to show a portal of small thumbnails on the side, with 1 large container. Clicking on a thumbnail sets a field in the parent table to that portal row's ID. Then the large related container (based on both IDs) shows the picture at full size."

"Or (even easier) pop up a new window with the full size picture. As long as they close it they should be OK. It would work much like the web. That would let you have many thumbnails; fill the screen if you need to."

If you could just expound a little on each of these techniques that will help me.

[Vaughan]

No need to paste the image into a global container field: just change layout (or open a new window into a layout) to one that has the conatiner field as big as you need it.

[Fenton]

The basic technique is to either set a field to the unique ID of the image (the primary key of the Images table). Or, as Vaughan says, to pop up a window of the full-size image in a new window. This doesn't even require setting a field, because you are basically just going to the related record in the Images table; but it does require handling the window. It can be done with the single Go To Related Record [] step, creating the new window of the correct size and placement.

Which you use depends primarily on how many of those thumbnails you have. If just a few, running down the side of a layout, then I would go for the "set an ID and show the big image in the middle." If you have an entire contact sheet, filling the screen, then popping up a new window with the full-size image makes the most sense.

Another consideration is how you want to add the images; thumbnail and full size. It is possible to do it all on the one layout, but it requires some understanding of what is going on. Or else a tool like AppleScript or Troi File plug-in, which can let you pick a single file, and handle making the thumbnail, and adding both the images.

FileMaker has one serious limit, which is that you can only create a thumbnail automatically with the Import Folder command. But this is a little clunky if you just want to add 1 file, which is currently in some arbitrary folder somewhere, along with a bunch of others.

If, as you say, you're going to Import the images, more or less manually, then you don't need to add them one at a time; and you don't really need a mechanism to add images on your viewing layout. You will need to have a system, a "folder to import", and file names that can be matched up (unless you want to match them manually visually later in FileMaker, which is fine).

I'm attaching a small file which has the portal with the big image technique. It also has an AppleScript script to get a file and create a thumbnail. But you'll have to ignore that (or buy a Mac :-) Troi File could do the same; it has such in its example files.

[Actually this file does it a little differently from what I said earlier. It sets the Image ID into a global field, not a regular field. Then it uses a compound relationship with the Main ID AND the global Image ID to show the big picture. What this means in practice is that if you flip to another main record, the big image will always be blank, until you choose one from the thumbs portal; rather than keeping the last one you'd clicked on each record, which a regular field would do. Just switch the global storage Off to see the difference. Either way works.]

ThumbsImages.zip

[Frink1234]

Thanks for the example file. I'm still working on the script to show the portal thumbnail in the big image container in my layout. I'll try to attach a couple of sample files in the next day or so if I'm still having a problem.

[Frink1234]

I can tell that my problem is with relationships (not only in working with FMP!)

Here is my problem: My main database is comprised of many clients who already have a unique number Client_ID. Per your example, I then created two new tables Images and Images_RecID_gImgID. I am thinking that my Main Table with client data is taking the place of your Recs table in your example. Therefore, Client_ID should be related to RecID in the two other tables. However I can't seem to get any of my Client_ID's to show-up in the Images_RecID_gImgID layout where the images are. Any ideas what I am doing wrong?

[Fenton]

Well, I had a main table, which had the RecID, and an Images table with the images. You don't really need 3 tables; because, if you look, there's nothing really in the RecID table. It's just there to provide a "one" table for the "many" images. Just use your Main client table, and use the ID it has. Put it into the Images table as the foreign key (hint: the foreign key is not the auto-enter serial ID, that's the primary key).

If the portal has "allow creation of related records," then putting a thumnail into a portal row will then create a new Images record WITH the client ID (primary ID of the main table) as a foreign key in the Image table. That's the way creation through a portal works.

That's the "one at a time" manual method of entering images however. If you import a folder of images, then obviously you're going to have to line them up with their clients; either via parsing the names of the files, or manually.

So there are really 2 (interrelated) problems when talking about bringing images into FileMaker. Bringing the photos in, and tying them to the right record (many photos to one client, or project, or whatever).

You should just try and set up and bring one in manually, using Insert Picture; typing the ID's in manually to line them up. That's what I did. My portal does not have "allow creation" turned on. I wasn't trying to create an image management solution (though I seem to be describing one). I was just trying to show how to use a portal to switch the big image, in the simplest possible way. There are only 7 fields in the whole file.

It might be best if you did the best you could, then uploaded a small file. Also explain what you intend it to do; both to show, and generally what method you're considering for adding images. You don't have to say exactly how, just the general idea.

[David Holmberg]

In 7 you do not need separate relationships to show multiple columns of the same portal. You can specify which row to start with and end with, very convenient for these situations. So the 1st column is rows 1-10, the next 11-20, etc., same relationship, same fields. You could do a "contact sheet" kind of layout with 1 relationship.

I've never noticed that despite working with 7 for half a year...

Thanks Fenton

[Frink1234]

Ok, I've attached a bare-bones file showing what I'm doing. I import images one at a time into a "preview" box and then transfer them into the portal with a script. My goal is to click on a portal image and display this in a large container and then return back to the same portal row. You can log-on with guest account and have full access.

TestImagePortal.zip

[Fenton]

OK. A few things. First, you need real serial IDs, in both tables, if you want to use relationships properly between them. The Photo table must have its own, so you can set a field in the other table and show that 1 related photo.

You do not need a global container in the main table for the big image. It is shown by relationship (which I created). It could be done with a global, yes, but it is wasteful to be continually moving images around. It is not really necessary to have that "preview" global either, but that's up to you.

One of your globals was Text, while its ID field was number. Not a big deal, but watch that, cause it can be a problem in 7 to match a number to text, especially if a calculation is involved.

A couple B fields were auto-entering, by calculation, themselves. While one might use something like this to strip formatting, etc., it does nothing otherwise; especially for a container.

I fixed my setting the global ID for the Image record script, so you can see the big picture as a related image. Your "Transfer" script to create the new image record was more or less correct.

One small problem to this whole setup is how to delete an image. It's dangerous, because if you delete the record while viewing the big image, you will be deleting the Main record, not the image. Not good. You could put a button in the portal to delete. Or a script on the big view layout (that's what I did).

One other factor, which you may not want to deal with. Turning on "Reduce" for a container field (ie., in the portal) does nothing for actually reducing the "size" of an image; by size I mean the actually file size, which determines how long it takes to load.

That is why a separate thumbnail file (container in our case) is so often used, on web pages, etc.. If you are actually showing the big picture (as you are), only visually reducing its size, it will take just as long to load as the big picture would. Since you have several in the portal it will take as long to load as ALL of those big pictures.

You can get away with it for a few, but not for large contact-page layouts, or list views. It depends partly on the file type of the images. Of course, if you decide to use real thumbnails it's (much) more work, unless you use a plug-in; or have organized folders of existing thumbnails and images.

TestImagePortal_100.zip

[Fenton]

Oh, and for David. There is the same feature for repeating fields. Which makes them a bit for flexible for layouts.

[Frink1234]

Ok, great help. I'm starting to get the idea of relationships and understanding a little better using ID's. That was a big part of my problem.

I see what you mean about the portal taking long to load if it's crammed with images. I'll have to decide if I want to use "real" thumbnails or not.

I like the delete button - I hadn't thought of that.

One more thing I'd like to do (there's always one more thing) is tie a caption to each image imported and display that along in the Show Big Image layout. (You can see I already have a field TextField in the B layout.) I should be able to use a similar Transfer Text script as I did for the photo which executes at the same time to store them together in the same record, yes?

[Fenton]

Well, if they're in the same record in Images, any field can show using that global ID relationship. Just put it on the layout, using that relationship. A portal is superfluous, as there will only be 1 match to that relationship (since it's targeting the unique ID of Images).

As far as theTransfer; sure, you could transfer a caption. Just make it another global field, text. Then Set it with the script. They can enter the caption before transferring. You could also make it editable on the big picture layout (above), so they could add/edit the caption later.

(P.S. For a little more than $50 you could get the Troi File plug-in, which could put up the File dialog, get the image, and create a thumbnail, which you could then set into FileMaker. Look at his Thumbnail example file.)

http://www.troi.com/software/fileplugin.html

[Frink1234]

Ok, I guess I'm still having relationship issues. I can get the text field (image caption) to transfer with the image to layout B just fine. The right caption with the right image in the same record. When I try to show them together in the big image layout the text for the first image shows-up fine but does not change when I change images. I missed a relationship somewhere, yes?

[Frink1234]

Ok, I figured it out. I was actually making it more complicated then it is!

[Frink1234]

I do have a question that might help me understand this better. I notice that you defined a relationship between PhotoID and B_gPhotoID under the Relationships tab yet I don't see a table under the Tables tab called B_gPhotoID. This confuses me.

[Fenton]

That is because the "boxes" you see on the Relationship Graph are NOT Tables. They are "table occurrences." You can (and will) have several table occurrences for 1 "base table" (a phrase coined to further clarify the tables which you actually define and add fields to).

Table occurrences are kind of a "alias" or reference to a base table. Relationships are attached to a table occurrence.

When you first define a table, FileMaker automatically creates both a table occurrence and a layout for it (I think so anyway). But after that you're on your own.

In this case we want to look at the Image table from the Main table; but in 2 different ways, once via a regular ID field tie (the portal), and once via a global field set to the primary ID of the Images table (ie., a value not even in the regular data of the Main table; much like a mirror, a very specific one).

If there was only 1 occurrence of the Images table we would have no way to specify the 2 relationships, or which to use. So, if you want to look at another base table via 2 different relationships, then you will need 2 table occurrences of the 2nd table.

You may be tempted to equate a specific relationship with a table occurrence, or want to name a relationship, like we did in 6. But a table occurrence may have several relationships attached to it. And, what is really different in 7, is that you can reach "through" one or several relationships to access or set data in a table occurrence that is several table occurrences away on the graph. It would be extremely tedious, and not all that useful, to have to specify every relationship on the way. You merely name the final table occurrence; the entire path to get there is implied, and visible on the graph as a series of connected lines (if not, it won't work).

[Frink1234]

Ok, I'm starting to get the idea. Thanks again for all the great help.