Building layouts in FileMaker can involve adding a number of various elements such as fields, buttons, portals, tab controls, and graphics such as jpg and png images. It is the use of images on layouts that this article is all about.
You may want to use image files on your layouts for a number of reasons, such as:
• A background fill, ie gradient image
• To be used as buttons, or links
• Images for design purposes, ie rounded edges, shapes, icons etc.
The simplest way to use images is to insert or paste them directly onto the layout. This can be done by pasting from the clipboard, or using the Insert -> Picture command from the FileMaker menu. When you use these options, the image is inserted directly onto the specific layout. If you then duplicate the image to be used on the layout, then 2,3,4.. and so on images will exist individually on the layout.
What happens if you then have 10 layouts, and you want to use the same image on each layout as a button? You could insert it onto the 10 layouts. In doing so, the image now exists in 10 different locations within the file.
FileMaker itself is smart enough to recognize that the same image has been used multiple times within the file, and so internally, it only retains one copy of the file. This means that a database file with 1 copy of an image in it, will be the same size as a duplicate version of the file, but with 50 copies of the image in it.
This might all seem fine, but what if you then wished to alter any of the images used in your system? Worse still, what if it is a particularly large system, with the same images used on many layouts for purposes such as navigation, or buttons?
If you were to follow the method above, it would require you to manually replace the image in question on every layout, a tedious and time consuming task. FileMaker does not give you any way to change the internally stored image within the file, when it has been inserted or pasted onto a layout.
The Alternative Approach - Using a Table…
There is, however, a way in which you can change images, and have them update everywhere in your system. This is achieved through using a special table called a Graphics table. In fact, any table will work fine, but it is good practice to keep your images that are used for User Interface purposes in their own separate table.
This special Graphics table will contain fields that are of the Container type. Containers fields are special fields that allow you to store things such as images and video, as well as files such as PDF documents or excel spreadsheets.
Let's consider a solution in which you have 10 icons you wish to use as buttons throughout the database. These icons will appear on many layouts. The first thing to do is create 10 container fields in the Graphics table, and name each field appropriately.
You will also want to set the storage of the fields to be "Global". Having the image fields as global, means that they will be able to be referenced from any layout within the file, without the need for a relationship between the layouts Table Occurrence, and the Graphics Table Occurrence.
Once the table is created and setup, the next step is to insert the icon images into the relevant container fields. This process should be done when the file is offline (ie not being hosted on FileMaker Server). By setting the container fields offline, the icons will remain in the fields when that file is later hosted on Server.
The icons are now all set and ready to be used. Rather than inserting images directly onto layouts, now you will be adding the relevant container field to the layout instead. It is the container field that will be displaying the icon now.
The beauty of the whole setup is that to later change an icon, all you need to do is change the icon in the container field, and it will change on all layouts where that container field is displayed.
Using this technique, you can take it further to achieve other kinds of functionality, such as:
• Multiple records in your graphics table. If your database has various levels of users, you can create a graphics record for each type of user. Each record contains slightly different graphics, and colours, so that the users have a different user experience, it can also be used as a way of distinguishing users in the system. The graphics record a user is assigned, and thus displayed, is managed internally in the system via relationships and other techniques.
• Very fast to alter a user interface experience. If you are developing a system for a user, this can be a great way to quickly change the look and feel of your solution, without completely redesigning the layouts. If you use container fields for background colours, fills, navigation, buttons and so on, then you can completely change the look of your layouts in a couple of minutes.