Global Repeating Image Field on FMServer

[jmkimmel]

I am building an in-house solution that is a stepping stone toward a solution with interface and data separated. In this solution, I am using graphics to draw attention to certain data by using a calculated field to display an appropriate graphic if certain conditions are met. So what is my problem? I have the images stored in a global repeating field within the file and the calculation pulls out the appropriate repetition. This all works fine up to this point.

Where I run into problems is that if I clone the database for distributing to another location using a separate FMServer installation, the images that I have inserted are no longer there without me going in and inserting them again.

I need a way around this. Is scripting an insert procedure on start up the best way or should I just relate another image database and just copy it site to site instead of cloning it?

[The Bridge]

One option:

Create a layout for each graphic. Set the margins to 0 on all sides. Paste the graphic into the top left corner of the layout. Also place your global container field on the layout and set it to Do Not Print.

Create a script that will:

Freeze Window

Go to layout (the graphic's layout)

Enter Preview Mode

Copy

Enter Browse Mode

Paste (Global Container field)

Go to Layout (original layout)

In your startup script, test for the contents of the global container field. If it is empty, you will have to create a new record, call the above script, and delete the record. The global will still hold.

I use this technique mainly for storing colour values in fields, since it's easy enough to set the body of a layout to the desired colour and you can set any container field storing that colour to Reduce or Enlarge (don't maintain proportions). With custom graphics you will likely want to Crop, maintain proportions, and align left and top.

Also, I've never tried this with repeating global container fields, so the Paste step may not work. I'm sure others will suggest a related file which stores graphics, which may be a better route.

At any rate, here's an idea for you.

[LiveOak]

The less elegant answer is not to clone you database, but to delete all records and save a compressed copy or to put all images in another file in the solution which is copied, not cloned.

-bd

[CobaltSky]

A further option, which I have found preferable in some circumstances, is to create a separate file which does not accompany the solution, but which opens the clone, creates a first record and populates the various global fields with the required graphics. A 'set-up file', if you like.

Such a file can have a calculated constant relationship to the files in your solution, and once it has done its 'load and/or refresh global data' job, it can be removed, leaving no apparent trace - and retained on hand for use next time you create a clone (or in the event that global data becomes lost or corrupted at any point for any reason).

The other solutions already suggested are worthwhile options also, and each has its advantages, so I'll leave you to decide which may best suit the needs of your current situation.

[Kurt Knippel]

An even better solution is to include a small file, whose sole pupose is to hold those graphics. Still make them global repeating fields. This file would never be cloned or records deleted, as it only contains the graphics and is just delivered as is.

[jmkimmel]

With this approach, you would then relate the database how? With a null relationship?

[Kurt Knippel]

Exactly.

[jmkimmel]

Cool.

Thanks Captain Kurt and everyone else that responded.