Import Image References to Container for both Mac and Windows

[ejpvi]

I am trying to come up with an efficient method for importing Image References to a database I am creating. Part of this Database is an image repository. I have an Item Table, Join Table, and Table that holds file path references to images.

This part works perfectly.

Where I am running into issues is: When a Mac User imports a folder of images from our server, the syntax is different than someone using a Windows Computer.

So when people view my database, if it was imported with a Mac, only mac users can see it, same way with Windows. Because the File Path is slightly different.

The actual images sit on a server available to everyone on the network... same location for everyone.

My question: what is the best practice to handle this? Write a script that somehow modifies the file path, based on something like get(PlatformVersion)... or is there a method I am missing?

Should I have a script that when I import it, handles the necessary path for both Mac and Windows?

I heard about maybe being able to use the filemaker network sharing to help with this, instead of using relative or absolute paths... not sure how to though.

Any help would be greatly appreciated... thanks!

[Fenton]

It does not have to be a script. You can create a calculation field, result of Container. If it produces the correct path, in FileMaker syntax, to the file, the image will show. The advantage of this is that you can add the current "prefix" part of the path for either platform, including the server name.

It seems a little weird perhaps to create a text calculation with a result of container, but it makes sense when you realize that with referenced images or files FileMaker only needs you to tell it the path. You can do that by Insert or Import; but you can also just tell it via a calculation.

You can combine the methods. That is, put the container field on top of the regular container field, opaque, non-enterable. So people can do their Insert/Import as normal. But what they actually see, when it's done, is the calculation field, which shows the same image.

The calculation is based on GetAsText ( regular container field ), then parsed and augmented to get the right path for the platform; or you can just have both paths, separated by a return (but I always just figure out which and have one).

This calculation does "file", but just change to "image":

Let (

LastLine = GetValue ( GetAsText (FileRef); ValueCount (FileRef) );

Case (

Abs ( Get ( SystemPlatform )) = 1;

Substitute ( LastLine; "filewin:"; "filemac:");

Substitute ( LastLine; "filemac:"; "filewin:")

)

)

Edited June 18, 2009 by Guest

[comment]

I haven't tried this, but I wonder if auto-entered correction of the path's prefix couldn't work directly on the original container field.

[ejpvi]

Thanks for the info, that is kind of what I was thinking I would have to do.

One issue remains. When Mac Users map their connections to the Server, it doesn't put the server name into the path. With Windows it does, so I would simply need to omit that part for the mac users.

I know the name of the server where the images are stored, so that could be hard coded, but what someone decides to add one from a different server. Any ideas?

[Fenton]

I guess it is all in there, in the part of the calculation, LastLine. So you could use FileMaker's Text functions to pull it, then decide what to put back. The problem is I think more on the Windows side, where you could get a different drive letter for the same server, if it was mapped differently. I'm afraid I'm bigger on theory than practice with this; I don't have multiple servers here at my humble abode :-]

[ejpvi]

Fenton, I was able to get this to work like you said. Seems to work as you said. I haven't tried the transparent container yet... but the calculated container does display under the right conditions.

But I fear it may leave too much room for mistakes. I am noticing a lot of different paths.

If I insert directly into the container, then I do see the imagewin: but if I import the folder, from either a mac or pc, it says image:

That, and I have to do tests to make sure, to omit the server name if a PC happened to import it. Seems like all sorts of issues could arise.

That, and if someone chose another server, the link simply wouldn't work correctly, because a mac seems to leave the server name out of its path.

I assume most people with Mac and PC container References have this issue? I am surprised there aren't several ways to address this.

I do appreciate your help, thank you very much! Parsing seems very powerful, just need to figure out how to prevent these issues. In case I am not here to fix the database at a later time.

[bcooney]

This is typically where someone mentions 360works' SuperContainer plugin.

(Haven't used it, but many happy users, I've heard).

[Fenton]

Yes, I suppose there are some possibilities. But I think they are limited. You have Get (SystemPlatform) to figure out which platform a particular user is using.

Since you likely only have 1 Server computer, you would only need 2 paths to it, a Mac path and a Windows path. So strip out whatever prefixes are on the file path, add the appropriate server path, and it should work. Windows people would just have to map the server to the same drive letter. If not, well, too bad for them :-]

[ejpvi]

The prefix replacements seems to work... but I am considering just having them import all of their images directly into a separate Filemaker Data File. I would rather not, because I like the idea of them being able to update images, and not having to re-import them. Do you know of any disadvantages to having them store their images into a Data File? Is it common practice? Or in your experience, do people prefer the link?

[Fenton]

As I said, I'm bigger on theory than practice with this, not having many clients with large installations of images. I've done some solutions with external files, and some with embedded images & files (smallish ones). Both work fine, for what they do.

The external method is just more flexible. If people want to work on the files, it is more convenient. Otherwise they would have to export the image file, open it, work on it, then reinsert it. If they forget that last step, the changes would not be saved in FileMaker. Awkward.

Also, if they have or need access to the image server machine itself, then they might put stuff in there which FileMaker does not yet know about. Yes, that is a PITA, but there are methods to deal with it. (These methods depend on either a well-known (to the database) folder structure, or file naming convention with IDs in the names.) On a Mac we can use AppleScript to create a FileMaker record for them. Cross-platform there are plug-ins to list the files, or FTP, or command line.

So, for solutions dealing with lots of large images, a separate file server machine, and maximum flexibility, then external is likely the path to go.* If on the other hand, you have a simpler system, with just smallish images and files, and rarely edit the files much afterwards, then embedded seems easier. And, as others have mentioned, there is also Super Container, which handles much of the work of an external system for you; though I don't know that is as flexible when it comes to people messing with the files directly (well, that is messy in any case).

There's a lot of overlap in functionality between the methods. You have to consider the details of your particular situation (now and future) to decide which may be best; in many cases all 3 would work.

*Custom web publishing also is going to want external files.

[bcooney]

Another point is the size of the fm files with embedded container images. Backup will take longer.

[ejpvi]

Well, thank you very much for your help. I created a case statement, and it replaces the prefix as you suggested, or adds in the server name. I will just hope they keep it centralized on that server. I will include in the technical document info on changing the hard-coded server name, in case they get a new server. So your method is what I am going with. Thanks!

[mm2]

I have been working through your solution for cross platform file pathway problems. I have used the double Container field with the calculation on top, however for some reason the calculation is not working. I have two container fields, one called Illustration which is just a container. On top of this is a Container called Illustration Calc with an auto enter calculation

Let ( LastLine = GetValue ( GetAsText (Illustration); ValueCount (Illustration) );

Case ( Abs ( Get ( SystemPlatform )) = 1;

Substitute ( LastLine; "filewin:"; "filemac:");

Substitute ( LastLine; "filemac:"; "filewin:")))

That enters fine in Mac but looking at PC side I get File cannot be found filemac:/and the path and the same with the PC side the other way round. I am using the imagemac/imagewin, and I have tried the filemac/filewin. I know I am dong something silly but I don't know what it is. Can you help?

[ejpvi]

Don't know if this will help you.. but when I was doing my testing across platforms I was getting weird results until I switched some of the calculated fields to: unstored,

especially the filepath calculation...

Apparently if you don't, you may see some overlapping results from Mac users/PC users...

[mm2]

OK this is really odd. When I do a Get System Platform calculation I am getting -1 on my macBook Pro and 1 on a PC. Is this to do with the platform on the Server or on the local machine, although the server is a windows machine.

[ejpvi]

That was the problem I was getting until I set the calculation storage to "unstored" because I was simultaneously testing on both platforms... since it isn't global, and if it is indexed.. you may see some strange results.

[mm2]

It is unstored. I just created another field and made it a calculation and used Get(SystemPlatform). That was the result. Do you mean that ALL the fields in the database should be unstored and not indexed or just the containers?

[mm2]

Could it be a Leopard problem conflicting with FMPro9?

[charisse]

I haven't tried this, but I wonder if auto-entered correction of the path's prefix couldn't work directly on the original container field.

This sounds very promising. I am also working in a cross platform environment and having the same issue. At present the images are on an external file server. When I import the folder from a mac the path reads:

 

image:/Public/FM Check-in Images/untitled folder/ck13-3734_001.jpg

 

mac users can see them fine, but my windows users cannot.

 

How would I go about generating this auto-entered correction of path? I can see in the container options where you can specify an auto entered calculated value, but I have no idea what the calculation would be or if this is what you are referencing.

 

Thank you.

[comment]

How would I go about generating this auto-entered correction of path?

 

Before figuring out "how", you need to find out "what" - i.e what is the path format that will work for your Windows users. According to the help file, the Windows absolute path to an image on a shared volume should look like this:

 

imagewin://computerName/shareName/directoryName/fileName

 

Once you have the correct path format, it's a relatively simple text manipulation to produce it from the existing Mac path.

[charisse]

Before figuring out "how", you need to find out "what" - i.e what is the path format that will work for your Windows users. According to the help file, the Windows absolute path to an image on a shared volume should look like this:

 

imagewin://computerName/shareName/directoryName/fileName

 

Once you have the correct path format, it's a relatively simple text manipulation to produce it from the existing Mac path.

 

 

Okay. I was able to map the path 3 different ways from the external file server and all 3 variations show the images on the windows computers.

 

image://name of external server/Public/ FM Check-in Images/untitled folder/filename

image://ip adress of the external server/Public/ FM Check-in Images/untitled folder/filename

image://Z:/Public/ FM Check-in Images/untitled folder/filename

 

on mac: image:/Public/FM Check-in Images/untitled folder/ck13-3734_001.jpg

 

I am thinking that any of the 3 would work, but the first seems to be the most absolute, although it would not be a problem to map all of the windows computers to the Z drive.

 

So I am assuming that the text manipulation would be a calculation in the container field? If so, I am a bit lost as to how to accomplish that task.

 

Thank you.

[comment]

Ok, so let's say your external server's name is "Pluto" and you have a Path field with the path that works on Macs (if not, you can extract the path from your existing container field, using the GetAsText function).

For test purposes, define a calculation field =

List (
Substitute ( Path ; "image:/" ; "imagemac:/" ) ;
Substitute ( Path ; "image:/" ; "imagewin://Pluto/" )
)

Set the result type to Container and see if this works for both platforms. If it does, you can set the original container field to the result of the calculation (make sure you have a backup before you try this) and remove the calculation field. Or keep the calculation field and remove the container field, if you prefer.

[charisse]

Okay, the calculation field works great!

But, if I use the calculation field as the original container I can no longer import images into that field. ?

[comment]

But, if I use the calculation field as the original container I can no longer import images into that field. ?

 

Well, yes and no. A lot here depends on your intended workflow. If you will always be importing a folder, you will have a choice of importing any combination of Image, File Name, File Path and Image Thumbnail. So you could import only the File Path and display the referenced image in the calculated container.

 

In many solutions, the path to the images folder is stored separately (e.g. in a global field) and the image name is calculated (e.g. from the product SKU). This way nothing needs to be imported or inserted into the container, and the images folder can be moved with relative ease.

 

In any case, as I said earlier, you can correct the path stored in the container field by setting it to result of the calculation. And, as I said much earlier (i.e. in 2009) you could set the container to auto-enter the correction on future modifications (still untested, though).

[charisse]

I haven't tried this, but I wonder if auto-entered correction of the path's prefix couldn't work directly on the original container field.

Yes, this worked perfectly on the original container. The image container has an auto entered calculation of:

 

List (

Substitute ( Image Path ; "image:/" ; "imagemac:/" ) ;

Substitute ( Image Path ; "image:/" ; "imagewin://NAS/" )

)

 

I imported the image and the file path from the NAS on my network.

 

The file path reads: file://Public/FM Images/014/13-4673_003.JPG

 

My question is, why does this calculation work when the file path reads "file" not "image?" Why does the file path read "file?" When I use the Get as Text the path reads "image."

 

Also, I have read in the FM help that when you import the "File Path data into a field, you can open the original file directly from FileMaker Pro: select the entire file path text, right-click the text, and then choose Open File from the shortcut menu." This does not seem to be the case. The option appears, but nothing happens.

 

Thanks!

[comment]

Yes, this worked perfectly on the original container. The image container has an auto entered calculation of:

 

List (

Substitute ( Image Path ; "image:/" ; "imagemac:/" ) ;

Substitute ( Image Path ; "image:/" ; "imagewin://NAS/" )

)

 

I imported the image and the file path from the NAS on my network.

 

The file path reads: file://Public/FM Images/014/13-4673_003.JPG

 

My question is, why does this calculation work when the file path reads "file" not "image?" Why does the file path read "file?" When I use the Get as Text the path reads "image."

 

I am afraid you got me confused there. `I think you meant it the other way around? Substituting "image:/" with something else cannot work if the container holds a file, not an image. I am not sure how you populated the field, but it is certainly possible to place the same image file in a container either as an image or as a file. It's also possible to convert between the two, again by substituting one prefix with another.

[charisse]

I tried this two ways. Same folder full of JPG's.

 

First time - I imported a folder full of images and stored as a reference. In the field mapping I imported the image into the calculated container and the file path into another field. When I look at the imported path it reads file://Public/FM Images/014/13-4673_003.JPG. Cannot right click on the path and open the image.

 

Second time - I imported a folder full of images and stored as a reference. In the field mapping I imported the image into a container (did not import the file path). I then used a calculated field to Get As text the contents of the container to populate the file path then used the resulting path to calculate a "cross platform" container. When I look at the calculated file path it reads image://Public/FM Images/014/13-4673_003.JPG. Can right click on the path and open the image.

 

The first method seems a lot cleaner especially since I import images regularly so I cannot delete the first container because I need it to obtain the path for the second container. But I would really like to be able to open the image with the right click shortcut.

 

Guess I don't understand how the same import could yield two difference paths. The only thing I can think of is maybe Filemaker doesn't know it is importing an image until it has already been imported. Hence the file:// prefix result from the import.

 

Thank you.

[Wim Decorte]

Check out this blog post:

http://www.soliantconsulting.com/blog/2014/01/references-embedded-container-data

 

These days there is very little upside in trying to do containers by reference.  

[comment]

I am afraid you may be mixing two separate things. The imported file path (text) will always have a "file:/"prefix. You would have seen this if you had imported it both times. The path stored in the container field (which of course exists only if you had actually imported something into it) will have the "image:/" prefix. So this is not a question of "how the same import could yield two difference paths".

 

 

The first method seems a lot cleaner especially since I import images regularly so I cannot delete the first container because I need it to obtain the path for the second container. But I would really like to be able to open the image with the right click shortcut.

 

 

Not sure what you mean by that. If you only want to import the file path, then do just that. If you prefer the path to have an "image:/" prefix, then use Substitute() to replace "file:/" with "image:/" (you have to do this anyway, if you want to show the image in a calculation field).

 

 

 

 

 

These days

 

OP shows v.11.