database images in filemaker

[Mark Appleby]

Is there some way to connect an image to a fielmaker record, having it visible yet not storing it in filemaker.

I have a system that would have within 2 years over 50,000 images as this would take enourmous ammounts of disk space and power, I need another way of letting the user see images most likely in jpeg format.

What should I do?

[SteveB]

Look at the Troi plugins...I think his file plugin will allow you do do what you want. www.troi.com

[Mark Appleby]

I have checked out this plug in but I dont think that it will do the trick. Ideally what I would like to do is click a photo in photoshop or some other photo editing software, copy the image and paste it into my database. When I paste the iamge I need to be able to see the picture in the container field, to a fair degree of detail. I want though to keep the jpeg in another file, just using a link to that file in the database, so as not to have my database grow to large. The problem with the Troi plug in that I can see is that it only helps you edit the photo in the filemaker file.

[IdealData]

Wish I knew the answer to this one as well, but consdier this...

FMP 5.5 supports the "file:" protocol, which can enable a browser to view the image. This is important because then you can resolve the directory acrchitecture difference on different platforms - you keep a path for each OS, and test the StatusCurrentPlatform to determine the path to use. Then OpenURL.

Even if you avoid storing the images in FMP, you've still got the problem of FMP not having a particularly good graphics engine. If you're using FMServer then the problem gets worse as you have to have the images delivered to your FMP client through the network AND THEN processed by FMP Client.

Web could be a better route !

[Anatoli]

Definitely web route. We have many pictures handled by web and the path is taken from FM database.

[kenneth2k1]

Forgive me if I am missing something, but could you just store a reference of the image?

Ken

[Mark Appleby]

Thanks,

Sometimes someone has to state the obvious. It is only your simple suggention that got me to find out how. Thank you because I didn't see how to go the "Web route", this might be a little advanced for me.

[kenneth2k1]

Youre welcome. Although storing a reference has its limitations (such as not being able to export).

Ken

[bme]

Excuse me if this posting is a bit elaborate. I'm desperate.

The obvious solution is of course the built-in "reference", just marking the check-box when importing. This is fine for many users. Soon problems may arise, though.

As Ken writes:

Even if you avoid storing the images in FMP, you've still got the problem of FMP not having a particularly good graphics engine.

I would say FMP sucks when it comes to graphics. E.g. simple drag-and-drop features WITHOUT use of plug-ins, should have been developed years ago. Amazingly enough, official FM retailers recommend Cumulus, Portfolio or other competing software for even the simplest needs when it comes to graphics.

I cite a post I made long ago:

"I am new to this mailing-list so please forgive me if I am addressing a subject already covered earlier...I am developing a large database for photographs in a cross-platform environment. A main feature of FileMaker is that it is cross-platform, even over a network.

Another is the container field where images can be stored, either inside the db, or linked with a reference to an image file outside the db.

Whenever constructing a db that is to handle larger amounts of images (i.e. virtually any serious, professional image application) you are forced to use the reference alternative, since otherwise the db would soon grow too big.

All the same it is explicitly stated that "When graphics are stored in container fields, referenced graphics will not be visible to guests unless they have mounted the volume where the graphics are stored before opening the database." (tech info)

As far as I understand, problems will arise because of the different paths in PC and Macintosh, as well as with mounting volumes cross-platform.

Does this actually mean that FileMaker no longer is cross-platform when handling images?

Thankful for any comment on this issue.

I have seen hints about using an URL to load the picture in a browser, or even changing program to Cumulus or Portfolio, but then the idea of developing in FileMaker is somewhat lost..."

Since then I have partially solved the cross-platform problem with a fairly neat STATUS(ST_Platform)-based relation. But I still have to do the linking twice to see the image in both PC and Mac. Another way of doing it is by performing the linking over and over again, through a user trigged AppleScript(Mac only...).

QUESTIONS:

1. Are there any solutions for the lousy Script-step "Paste image". This only leads to a dialog-box forcing me to CHOOSE the image. Why would I want to script that? (Step may be called "Import image" or similar. Sorry, I use a swedish version)

2. I develop in Macintosh. I am willing to surrend to PC developing as well. Any freeware tips for a PC equivalent to AppleScript? FMP-compatible? But why?:

3: When trying to view referenced images without having mounted the image storing server, you simply fail. No message, no prompt (occasionally I get one), just that annoying "Cannot show image XYZ.JPG" in the container field. Where can I find the error code? The path? The excuses? The "this bug will be fixed in version 5.xxx"?

Most grateful for any answers to any of these issues. (Please do not propose Troi plug-ins, there MUST be an plain FMP solution. At least that is the software I bought)

Platform: Mac and Windows2000

Software: 4.0, 4.1, 5.0, 5.5 Developer, 5.0 Unlimited, AppleScript.

[LiveOak]

I'm guessing that the Troi File plug-in will probably solve your problem. We have built a complex system for handling and categorizing 100,000+ photos for a client. The system includes automated import from photo CD's.

The problem you have with a reference is that the network volume on which the referenced photo is stored must be visible from both platforms. This isn't really a bid deal, but pretty much requires that you operate two servers, one for FM and another for general purpose file serving (either AppleShare IP, OS X, or some flavor of NT). For speed and file size reasons, we use a two step approach. 1) We use Troi File to import thumbnails of images we store in FM. When you click on an image to "zoom in", we use Troi File to import the image into a global field in FM. Troi File allows you to manage the paths to the images on both platforms.

What you want to do is certainly possible (we've done it), but takes a little advanced programming with Troi File, requires platform selective scripting, and does require a file server in addition to a FM Server.

-bd

[kenneth2k1]

Thanks to LiveOak, I will most certainly look into the Troi File plug-in also.

Ken

[bme]

Thank you for answering my post. I am still interested in avoiding the use of third party software like Troi. I have successfully used their plug-in and there is nothing wrong with it, but my point is that it shouldn't be needed for the simple task of extracting the path to a referenced image no matter what platform or server. (I DO use a separate server; a mac-enabled Windows NT: works perfectly)

The simple question is:

How do I extract the path to a referenced image from FileMaker?

It must be stored someplace. (Troi found it...) Does anyone in the FileMaker universe know this?

[kenneth2k1]

Just a Correction:

Mark Dore said "Even if you avoid storing the images in FMP, you've still got the problem of FMP not having a particularly good graphics engine."

Thanks

Ken

[LiveOak]

You're stuck either way. Either you use AppleScript/DDE/VB, which is platform specific; write your own software using system calls, which is platform specific; or use Troi plug-ins, which at least are available on both platforms and integrate the same way on both. The only way to avoid this is to have FMI write the functionality into FM (essentially what a plug-in does, in an add-on sort of way). Cross platform scripting and plug-in are really not a bad solution, considering the additional functionality and their ease of use. You see how FM gets the path, it makes system calls to pop the dialog for you to find the path!

You just have to get to the acceptance part of the solution.

-bd

[bme]

Thank you LiveOak, for the quick answer.

I just wanted to be sure I hadn't missed any easier solution than using plug-ins or convincing FMI that their products (in my view) are incomplete. I'll propably try the AppleScript/PC-script solution, i.e. if I come upon any fairly easy PC-scripting tool (I'm quite unused to PC, do you know of any? It doesn't come with the system like AppleScript, does it?)

The AppleScript part is a.p.o.c. If anyone still reading this post is interested it's enclosed below.

I'll be working on the acceptance part....=o<

a variety of the AppleScript runs:

tell application "FileMaker Pro"

activate

tell database "YourDB.FP5"

set gPath to cell "RefPic" of current record

display dialog "the path is: " & gPath

end tell

end tell

(the value of "gPath" can be used wherever you want in FM. Calling or executing the AppleScript is a ScriptMaker step)

[bme]

Sorry Ken. You are right, I was mixing it up. I cited Mark Dore.

[LiveOak]

I'm not sure why you are resisting the use of plug-ins. Of all the solutions offered it is the easiest by a factor of 20, is more stable than scripted solutions, and is cross platform. FM Server will even install and update plug-ins automatically. We use Troi plug-in's in a very complex client solution to store, manage, and categorize images (200,000 images and a storage capacity of 240 GB). If your labor is worth anything, buy the plug-in.

-bd

[DykstrL]

I don't know if this would work for this scenario, but it work - however limited:

If all you want the users to do is view the image and you happen to have a web server available, you could put the image files is a directory on the web server, then in a link field, place the http address of the file in the field ( i.e., "") Then set up a script with the Open URL script step using the field value of the link field. It will open the image in the user's default browser.

The downside is that the user would not be able to size the image if it is too big to fit the screen.

It is kinda kludgy, but it is a cross-plaform solution.