Over the years, I’ve spent quite a lot of time on calendars. It seems that most apps require some form of calendar functionality, and I’ve found it difficult to find or make one that does what I need it to, quickly and without costing too much.
The clever people at iGeek came up with a tidy solution a while ago, involving a device-specific table of calendar dates, refreshed whenever the user selects a new month. For the month view, the display is via 7 filtered portals, one for each day of the week, with a maximum of 6 records for each day. (Note that any changes to the calendar require work on each of the 7 portals, which is a nuisance, but which is a huge improvement on the 42 portals athat I’ve seen in other calendars!)
It worked really well in a LAN setup, but became a little slow over the internet, due largely to the handling of records each time the month changed, and the need for a ‘replace field contents’ with each refresh seemed especially slow. So, working on iGeek’s solid foundation, I converted the solution to use a ‘virtual list’ (i.e. with the data held in global variables). While I was at it, I also incorporated the ‘selector-connector’ method of linking tables (i.e. using a dedicated global field – called ‘XJOIN’ – to relate all the tables via a cross-join relationship). This is another technique which I picked up from my friends at iGeek, and one which I really like.
This resulted in a considerable performance improvement. At this stage, the calendar doesn’t do a great deal, apart from displaying a mini-calendar for the month. The user can scroll through previous and next months, and select a month and/or year. Clicking on a day performs a script which selects the date, and creates an ‘event’ for that date. The next version will enable the user to record details for the events, and there will be a week and day view, powered by the same virtual list.
I realise that I’m reinventing the wheel here – there are dozens of perfectly capable calendars out there – but as a learning exercise, it’s been very useful, and will ultimately be incorporated in my solution. So I thought I’d put it up for grabs in case anyone else felt that it could be useful.
The unlocked demo file is available here. It is, of course, offered with no guarantees or liability., but I would welcome comment or question.
The file comes complete with a virtual list table, VL_CalDays. Like any VL table, this has records of which the keys are sequentially numbered from 1 – this is the crucial part of the virtual list tecxhnique, as the record number will be used to populate the corresponding repetition within the global variables. If you need to re-build this table, there’s script in the file to enable you do so – ‘Create VL recs’.
If you’re new to virtual lists, you may want to read an article I wrote about the basics of virtual list a while ago, in ‘Virtual Lists – Let’s Start at the Very Beginning‘ (many other articles are available – I find Kevin Frank’s stuff at Filemaker Hacks especially well written and useful).
I really like popovers – they’re the most useful interface feature to have been introduced to Filemaker for ages, and being able to add an OnObjectEnter script trigger adds to their usefulness, enabling us to do some stuff each time the popover opens.
But OnObjectEnter is a “Post” trigger (i.e. it runs after the event has happened), and sometimes it’s nicer to do the processing before the popover opens. Initialising fields is a good example, because we don’t want the existing (“old”) field contents displayed, however briefly, before the fields are cleared.
One way around this is to have:
- An ordinary (non-popover) button, which is the button visible to the user, and which the user clicks.
- A popover button, hidden from the user. (To make it hidden, I use the method suggested by ‘bfroo’ in the comments – ‘hide object when 1’ – so that it’s always hidden in Browse mode, but visible in Layout mode.)
- An object name for the popover itself.
I tend to put the popover button next to the other button, but different in colour to make it obvious that it’s not a part of the user’s view of the interface, like this:
(i.e. the ‘Analyse’ and ‘Outcomes’ buttons are the clickable buttons, and the little yellow ones next to them are the popover buttons.)
When the user clicks on the (non-popover) button, a script is performed. This script:
- Performs any pre-processing required,
- Goes to the object name of the popover, which has the effect of opening the popover.
- Refreshes the window.
The disadvantage is that it’s obviously a bit more work to set it up in the first place, but the added flexibility that this technique provides, makes it well worthwhile.
I’m really enjoying my first forays into FM12 – many things seem much easier, and often more elegant.
One example is the handling of buttons to switch a Boolean indicator on or off (on attendance registers, access indicators, etc.).
For example, I have a field called “IsDisabled” in the People table. It’s on (i.e. set to 1) if the person is disabled, off (0) if not. (In the old days, this was a “yes/no” field, but this caused me all sorts of frustrations and limitations – Boolean is the way to go.) To amend and display this field, this is what I do:
- On the layout, rather than the field itself, I have a small button. It’s 15×15 on the desktop version of the layout, 34×34 on the iOS versions, with nicely rounded corners, consistent with the excellent River (or River Touch) theme that I’m using.
- The button just toggles the field, e.g. Set Field [PPL::IsDisabled; not PPL::IsDisabled]
(Note that the “not” has the effect of reversing the current setting – 1 becomes 0, 0 becomes 1.)
- The button is filled with a suitable colour – I use a solid green, to indicate “on”, with conditional formatting to show “no fill” if the field is not set. So the formatting is:
Buttons in FM12 have several states, and these can be used to fine-tune the user experience. I choose, for example, to use the solid green colour for the “Hover” state, as well as the “Normal” state – i.e. if it’s currently “off”, it will show green when the user hovers over it, to show what will happen if s/he selects it, but if it’s “on”, it will continue to show green on hover. When making this decision I was led by Google Apps, and it does seems the most “intuitive” way to present it.
What I like about this technique is that it’s really simple, and uses FM’s own stuff. Others may choose to use a graphic indicator (an arrowhead maybe?), and other non-FM tweaks, as I have done in the past, but after many hours spent fiddling with “home made” interface elements which sometimes end up looking wrong (or just different) on different screens etc., I’ve resolved to use native FM features in the re-write wherever possible.
As the developer and supporter of a fairly mature, stable application in FM11, I’ve been thinking about converting it to “.fmp12” format. One thing that’s been putting me off is that it will be a re-write, rather than a simple conversion – there are a lot of design flaws in the current system, and it’s the obvious opportunity to put them right.
So I’ve decided to bite the bullet. The features of FM12 that have tipped me into this big decision are (in descending order of importance):
- The option to develop versions for iOS devices on FM Go.
- Access to the ExecuteSQL function – I can see this being really useful, and greatly simplifying my massive relationship graph.
- The much-improved charting function.
- Improved layout tools, including the nice themes.Window styles, especially “modal dialogs”, which will make life a lot simpler.
I’ll mention any particular issues, difficulties (and even good things!) that crop up during the process.