Follow us on Twitter

Weetbicks

Creating a Graphics table for your User Interface

by Daniel Wood

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.

Comments

KathyO on 31 December, 2014

Glad to find your blog. Finding it clear and conversational on thinking out FMP solutions and use. This one helps a lot, been working on smarter solutions to maximize the power of the database solutions. Thanks for sharing!

Daniel on 31 December, 2014

Hi Kathy, thank you for the kind comment. If you have any requests or ideas for articles subjects you would like to see, be sure to flick me an e-mail to daniel@digitalfusion.co.nz , or via twitter. Also, if you have any questions about this or any of the other articles, be sure to let me know. Thanks again!

Martyn Ford on 30 May, 2014

This would be ok if it worked with server 7 and above but it does not and it gets messy.

Daniel Wood on 30 May, 2014

Hi Martyn, are you able to elaborate any on what you mean? Cheers.

Paul on 14 October, 2014

Another benefit with multiple records in a graphics table is having dynamic graphic elements (I usually define with globals specific to the layout), such as sort direction arrows, checkbox's, buttons, etc. Good for when you want something not text/symbol based and more visually appealing than conditional formatting.

Pablo Ruiz on 22 February, 2014

First: thank you for sharing. I read this somewhere and am using it somewhat. I have a quick question though. I've taken my DB offline to make the graphics. I've taken it online and it works great. In order to make any changes to the graphic objects, (and have those changes stick) I'd have to make these changes offline as well, correct?

Daniel Wood on 22 February, 2014

Hi Pablo. If you are using container fields which have global storage then in order to change the graphic in them you will need to take the file offline - that being off FileMaker Server in order to change the global. The reason is that once a file is put on server, the values in the global fields will remain as defaults for when you open the database. If you aren't hosting the file, or if the container fields are not globals, then you should be able to just change the contents whether you are on server or not.

Something to say?

The is a flightless bird and a symbol of NZ

Some HTML is OK
  • <b>bold</b>
  • <i>italic</i>
  • <blockquote>
    blockquote
    </blockquote>
  • <pre>
    preformatted code
    </pre>