January is just a click away

I've been using FileMaker for many years now but I can still stumble across features that bring a smile to my face. Earlier this week I clicked into a date field that was configured to show the standard FileMaker drop-down calendar. As expected, the calendar was displayed but in the time it took to make a few nervous clicks I'd transported myself back to the year 1992.

How did this happen?

Clicking in the title section of the calendar effectively navigates one level back up the "calendar tree". I was originally looking at the 18th of October 2012 so with a single click I was able to select from any month in 2012.

Another click and I was able to select from within a range of 12 years, in this case 2009-2020

One final click and I was able to select from 12 different decades, 1990-1999 through 2100-2109.

Clicking into any of the calendar options provided drills back down into the previous display option, e.g. when viewing the monthly calendar one click will take you to the month selection options, selecting one of these options will return to the standard month view.

Most of you probably knew this, heck I might have even known it myself at some stage but it brightened up my day when I discovered it earlier this week.

Update: As I was writing this article I found that the drop-down calendar behaves differently between Mac OS and Windows. While the Mac OS doesn't provide the same "time travel" interface as Windows, it does let you switch to other months within the current year via a nifty drop-down menu or jump to the same date for the next/previous year using a convenient button next to the month name. 

What plugin version do you have installed? Are you sure?

We've recently migrated our in-house systems across to FileMaker 12 and are carrying out a thorough review of the new features available in the latest offering from FileMaker Inc.

One of the features we were excited about is the new Install Plug-In File script step. When combined with the get(InstalledFMPlugins) function it allows scripting of a process that checks that plugins are installed and provides a mechanism to install the plugin on the local machine (if not installed or incorrect version)

From our own experience this sounds great as we've had plenty of issues where plugin were not installed, older version were installed or end-users had difficulty in locating where the plugins should go.

Unfortunatetly, the quality of information reported by the get(InstalledFMPlugins) function makes it less useful than it might be. The issue arises from the version information returned.

The help documentation describes the Purpose as follows:

Returns the name, version number (if available), and enabled state of installed plug-ins

The main hint is that the version number is returned, if available. Further clarification is provided in the description section of the help documentation

Get(InstalledFMPlugins) returns plug-in version information only when plug-in developers have entered version information in the resource file (Windows) or the info.plist file (Mac OS).

Looking at the information returned from the plugins we've got installed there are significant differences between the reported version on both Mac and Windows.

This obviously comes back to the information specified by the developer when coding and compiling their plugin. Given that there doesn't seem to be consistency between development companies (or even plugins from the same developer) we'll continue to use the version checking function unique to each plugin.

We've always found this to accurately report the version of the plugin installed.

A simple shortcut for moving your layout parts

Occasionally when you’re working on layouts, particularly those with multiple sub-summaries you require the flexibility to change part heights without all objects and parts below being moved. The process of rearranging objects can become time consuming as you extend parts and select and drag objects until you get everything in the desired location.

One easy way to change the height of a layout part without shuffling the objects below or being limited by the position of objects above is to use a modifier key when resizing the part.

Holding the Alt key (Win) or Cmd key (Mac) will allow you to drag the bottom boundary of the part across other objects on the layout (up or down). Normally, dragging a layout part further down will move all objects below it the same relative distance. In most cases this is what you want, sometimes it’s not. With this modifier key, you get to choose.

Carriage returns and the case of the disappearing data

Over many years of developing FileMaker solutions I've been flummoxed on more than one occasion by the invisible foe that is – the carriage return.

My broad recommendation?

Don’t allow entry of carriage returns into a field unless :

• You have a lot of spare time on your hands and enjoy troubleshooting client problems.
• The fields in question specifically require carriage returns, e.g. large blocks of text which require paragraphs to be included within the text.
• You (the developer) are controlling the insertion and removal of carriage returns because you need them for establishing relationships or other developer controlled trickery.

For those of you who haven’t already come across this issue I’ll explain why it happens and what the consequences are.

Mr Average User is entering data into the database and hits the Return key after typing in the required value. Pretty standard stuff for an Excel power user and he expects things to work the same in FileMaker. When the cursor doesn’t switch to the next field in the tab order he uses his mouse, clicking into the next field on the layout. No harm no foul as far as he’s concerned.

What the user doesn’t realise is that they’ve entered the value they intended plus an extra character, the carriage return.

The day continues on and then later that day, the next day, next week or a month later some peculiar behaviour is reported.

A particular customer’s last name isn’t being shown on printed invoices. The user verifies the data shown on the screen is correct and everything seems ok. The problems arises when a concatenated field is using one or more fields that contain carriage return. A simple calculation like Firstname & "" & Lastname produces unexpected results.

Instead of returning John Smith we end up with

John

Smith

The field on our print layout only includes provision for one line so the lastname is not shown at all, even though the user sees the value recorded in the Lastname field for the relevant contact. Let the confusion begin!

This scenario can also cause problems when you’re passing script parameters separated by carriage returns as you’ve got more values than you were expecting.

How can we avoid this problem?

• Configure your fields so that Field Behavior includes Go to next Object using Return.
• Check any data you’re importing from other data sources doesn't include superfluous carriage returns.
• Don’t assume that just because you can’t see a problem, there isn't one.

Pick a button, any button – so long as it’s the first one

Recently, I was using the Show Custom Dialog function to provide a series of options to the end user. My original intention was to allow input of 3 alternate phone numbers and then depending on which button was selected, identify one of the phone numbers as the default/preferred.

In my initial testing it seemed to be working ok however after further testing the process began to fail. A quick session with the debugger confirmed that it was working ok sometimes, but not all the time. The script looked ok, the logic seemed correct, but still no joy.

If all else fails – RTFM. A quick review of the help entry for Show Custom Dialog uncovered a specific detail that I wasn’t aware of.

Given I can configure the buttons to be labelled in any way and also script the underlying logic to behave differently based on which button is clicked I’m not sure why this restriction is required.

But, at least I’m now aware of this behaviour - and so are you.

Moving layout objects can be a real drag

Ever wondered why you couldn’t drag and drop some objects to the required location on your new layout? It was working in others ok so why not this particular layout?

The Page Margins option under the View menu (available in Layout Mode) stops objects from being dragged outside the printable area.

While this is helpful to stop objects being inadvertently moved outside the printed area it doesn’t distinguish between a layout intended for printing and one designed for user interaction. Layouts intended for user interaction will generally use areas on a layout that are beyond the standard print dimensions. While you can still use the arrow keys to move selected object(s) outside the printable area this is much slower than using drag and drop.

The solution? Pretty simple really, just de-select the Page Margins menu option and drag your objects anywhere you please.

Note: The Page Margins preference is associated with each file so a set of open files can have a variety of Page Margin settings (some showing margins, others not).

Extra Insight - Take particular notice when connecting remotely to client solutions. It can be confusing (and time consuming) if you don’t realise that Page Margins have been selected before starting some layout modifications.