Useful Tips For FileMaker Developers
My colleague and I meet every couple of months with a few local FileMaker developers (local to Bristol and the South West) with the intention of having a decent meal and a couple of drinks at the much to be recommended Fox & Goose Inn. We also get to discuss FileMaker, which some might even say is the primary reason of the meeting (it is, after all, under the purview of the FileMaker User Group or FMUG).
In any case, recently, we had one of our bi-monthly FMUG meetings where I showcased a few of the techniques that I use day to day to make my life a little easier, as a FileMaker database developer.The Overview Page
When creating a database, if you're sensible, you'll end up with a large number of notes about how the various features within the database work, the logic behind complex aspects of how the client's business operates and perhaps a glossary of terms. If you're not careful, these notes can be strewn across multiple media (paper, apps, hard drives and so on). This mess of notes can be a real bind to search and review a few months down the line when you've forgotten the specifics of a process (something which you were certain you could NEVER forget so didn't record properly).
Every developer should retain as much control as is reasonably possible over this information in order to :
- Act as an aide-memoire for future development work.
- Provide other developers with a much better understanding of how the database works.
- To help enforce the routine of creating these notes in the first place.
- Enforce recording of when a particular feature was requested by the client.
My suggestion for hitting all of these requirements is to create a primary database developer layout where you can store all of the important notes. The layout should be accessible by standard users and must be marked clearly so that it isn't deleted in error. You can either create the notes as text layout objects (ie hard coding this essential information so it can't be easily deleted) or you can create a Notes table where the notes are stored as records (you can ensure that only Full Access users can access / delete any of it).
Having a developer layout is a smart way of ensuring that the database notes always stay with the database.The Hidden Developer Features
I love the "Hide Object When" feature in FileMaker - you can put it to such good use. I like to employ it for developer notes by creating an object which can be viewed in layout mode but hidden in browse mode (ie "Hide Object When" is set to 1).
I prefer to make all of my hidden notes glaringly obvious in layout mode so they can't be inadvertently deleted, hence they're all white text on a mid-pink background (I've never had a customer asking for anything quite as garish as that). How would you use them? Well, let's say that you have a layout object which, because of having no background colour, no borders, etc, is invisible or difficult to see - you could place a hidden developer object (in bring pink) right next to it so that it's made obvious to you and no one else.
Hiding objects in plain sight can be extremely helpful so I'd certainly recommend that you make use of the technique.
I often find my self using developer scripts again and again but it can be a pest to search for them in the script menu or to hide them way in a Custom Menu. Instead, I'll create a slider using the pink / white formatting described earlier and hide them in plain sight somewhere obvious. The difference here is that "Hide Object When" is set to "Get ( AccountPrivilegeSetName ) ≠ "[Full Access]".
The slider contains a series of icons which run the scripts that I'm making frequent use of (eg I have one icon script set to open the Developer Notes layout described earlier). Having a developer slider can really help you to reduce the layout clutter and some of that unnecessary repetition.
Upon occasion, I like to remove objects from a layout but keep them....just in case. Sure, I can back the layout up (ie duplicate it, give it a sensible backup name with a date and then store it in a Backup layout folder) which I often do but sometimes, I like to keep it closer to hand. In these cases, I create a tab object and then place it offscreen. I'll name each tab appropriately so that I can't miss where all of my backed up layout objects are. Any layout objects I want to preserve then get placed in the relevant tab for easy access. You need to be a little careful here as offscreen objects are still accessible to scripts and will create layout loading overheads so it might be best to clear them out every now and then to mitigate that.