Layout tip – Opening a Popover with a Script

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:

  1. An ordinary (non-popover) button, which is the button visible to the user, and which the user clicks.
  2. 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.)
  3. 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:

popover_buttons

(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:

  1. Performs any pre-processing required,
  2. Goes to the object name of the popover, which has the effect of opening the popover.
  3. Refreshes the window.

E.g.

goToObject_popover

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.


On/Off (Boolean) Fields

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.

Image

  • 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:

cond_format_ind copy

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.


“Tidiest Drop-Downs” – Part 2, Finishing Touches

In the previous post, I documented how I plan to use a combination of drop-downs and pop-ups to get the best of both worlds, in terms of user-friendliness.  I’ll call these “tidiest drop-downs”.

But there’s one problem with the technique, which is this: because the key field is the one that the user actually enters data into, it’s possible for the user also to enter invalid data.  The intention is to limit the selection to items that are in the value list, but if the user double-clicks in the field and starts typing, invalid data may be left in the field.  (Of course the user may, by chance, enter a valid key value – just as a chimpanzee, left to its own devices, may eventually type the Complete Works of Shakespeare.  But it’s unlikely, to say the least.  And I’m not for a minute implying that my users are in any way like chimps…)  So anyway, we need to use a triggered script to make sure that this doesn’t happen.

On the key field, I’ll add an “OnObjectModify” script.  This will run either when the user selects a key value from the drop-down list, or when s/he types in the field.  The pseudocode for the script is:

Check whether the field holds a value that exists in the value list.
If so, do nothing.
If not, display an error message and offer the drop-down list again.

A couple of pre-requisites for this script;

  1. It has to be as portable as possible.  (I don’t want to have to write a new iteration of the script for every drop-down in the system.)
  2. Once the script has detected invalid data in the field, I want to throw the user back into the field, complete with drop-down list displayed (without the user having to click into the field again).

So this is how it turned out in FileMaker:

valid_dd_scriptNote that the script uses two custom functions, both of which can be found on Brian Dunning’s site.

  1. “GSP” – which gets the specified parameter from the parameters passed to the script.
  2. “FilterList” – which checks for the presence of a value in a given list.  (It does a lot more than this if you want it to, but that’s what it does here.)

Note also that you need a “dummy” field to go to, either during or after validation.  I have the dummy field (a global) parked just off the displayed area of each layout in the system – it often comes in handy.

So, the first parameter is a comma-separated list of all the (key) values in the value list that is attached to the field. (They have to be comma-separated, rather than cr-separated, so that the list will be treated as one parameter.)

The second parameter is the OBJECT NAME (not field name) of the field being validated.  We need this in order to get back to the field if validation fails.  So, for the script to work, you must give the field an object name.

So the script checks whether the contents of the active field exists in the list of values.  If it does, fine – just go to the dummy field, and end validation.

If the value doesn’t exist, then something’s obviously wrong, so show the custom dialog, initialise the field, then go back to the field in question.  Note the need to go to the dummy field first – if you don’t (i.e. if you go straight to the field being validated), the drop-down list will not be displayed – you haven’t actually left that field yet, hence the need for the little round-trip.

Note also the need to use “Go to object” rather than “Go to field”.  Although we can pass the field name as a parameter to the script, we can’t use that information once we get here, because FileMaker haven’t yet come up with a “Go To Field By Name” script step.

And that’s it.  A nicely portable validation script to help keep the solution free of invalid data.


“Tidiest Drop-Downs” – Part 1, The Best Compromise?

There’s no perfect solution when it comes to enabling users to select an item from a value list.   Usually it comes down to a choice between a drop-down list,or a pop-up menu.  These are similar, but crucially different.  These are the pros and cons of each, as I see it.

POP-UP MENU

Pros:

  • Easy to implement,
  • Easy to use – IF there are only a few items in the value list,
  • If the Value List is made up of 2 fields, it’s easy to show the resulting text value (field 2) but store the key value (field 1).

Cons:

  • No type-ahead functionality, at least on Windows – so, to go from A to Z, user has to scroll,
  • The menu will fill the available space – this can look really ugly.

DROP-DOWN LIST

Pros:

  • Look tidy, as only some values are displayed (about 15?),
  • User can type one or more characters to go the required part of the list.

Cons:

  • If the Value List is made up of 2 fields, it’s not possible to say “show the text value, but store the key value” (as you can with the pop-up).

Until now, I’ve gone for the tried and tested technique of using a drop-down menu to display the available values, with another field, holding the key value, UNDERNEATH the displayed field showing the text value.  (I documented the technique here.)  By setting the hidden key field to allow data entry, and setting the text field NOT to allow data entry, you get the best of both worlds … to a point.  One shortcoming of this technique is that, if you want the user to see an arrowhead as an indication that this is a drop-down, you have to make the text field on top a bit less wide than the key field beneath in order to show Filemaker’s native arrowhead.  In the wonderful world of FM12’s layout themes, this all gets a bit a bit messy, and has always been fiddly.

I’ve now realised there’s a better option, and this is the approach that I plan to use in future (i.e. until something better turns up!):

  1. Define the key field “underneath”, based, as before, on the 2-field value list.  As before, this is a DROP-DOWN menu, allowing field entry (in Browse and/or Find modes, according to the circumstances), but don’t enable the “arrow to show and hide list”.
  2. Add the same field on top of the key field.  This one, however, is a POP-UP list, with NO field entry.  The 2 stacked fields should be exactly the same size.

The result is that the text value is displayed, thanks to the behaviour of the pop-up menu, whilst the type-ahead selection behaviour of the drop-down list underneath makes things more user-friendly.  The added bonus is that the arrowhead of the “on top” pop-up menu appears to belong to the drop-down menu, completing the “best of both worlds” solution.

Note, however, there’s still a drawback with this, and it’s a big one – the user is able to double-click in the key field, potentially typing an invalid key value in the “underneath field” – more about this in the next post.


Conversion to FM 12

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.