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.

Advertisements

Mutually exclusive Booleans

The requirement:  A set of mutually exclusive fields, to be stored as Booleans (i.e. 1 or 0, on or off).

Demo file: Mutually exclusive Booleans

Note – There may be several reasons why these must be separate Boolean fields, rather than one non-Boolean (which would obviously be easier to implement) – totalling and reporting, for example, can be  much more straightforward with Booleans.

In a simple example (see demo file), we have 3 fields, isRed, isGreen, and isBlue. If any one of them is set to 1, the other two must be set to zero.

This is how I do this, following advice and tips from Technet members and others.

First of all, each field is shown as a checkbox set, using values from a value list called “true”. This VL actually only has one value in it, i.e. “1”. The field is sized on the layout to show only a single checkbox. Like this:

rgb_layout

Then, each field is defined as a number field, with two auto-enter settings:

  • Data – 0 or 1 (i.e. this determines the default setting),
  • Calculated value – as shown below:

rgb1

So, basically, this calc says:

  • If the field currently being updated is isRed, set isRed to whatever the user has selected, i.e. 1 or not. But, because we want to store a zero to indicate the “off” state, use the GetAsBoolean function to achieve that.
  • If the field currently being updated is isGreen, and if isGreen is “on”, set isRed to “off”.
  • If the field currently being updated is isBlue, and if isBlue is “on”, set isRed to “off”.

Each of the other two fields have a similar auto-enter calc applied to them, like this:

rgb2

rgb3
Note that the confusingly-labelled setting “Do not replace existing value of field (if any)” is set to OFF.
There’s another post on this blog advocating the use of conditionally-formatted objects to indicate on/off states of Booleans, but I’m now beginning to prefer this approach.  As ever, if you know of a better way to skin the cat, do let me know!


How to go to a specific portal row

The requirement:   In a portal, you need to be able to highlight a given record, and ensure that the portal row is visible.  (For example, a portal contains 20 records, but displays only 3.  You know which record you’re interested in, and you have the id of the record stashed in a global field, but the record may be out of sight when you display the portal.)

I devised a functional, but clunky, way of achieving this, then asked for advice on the Filemaker Technet.  I got 2 really good suggestions.  The first, from David Jondreau, suggested this:

portal_row_highlight1

So, the portal shows sessions (SSN) within a programme (PGM), and the id of the session that we’re interested in is held in the global field PGM::CURRENTSESSIONID.  The loop just goes through the portal rows until it hits that record.  “Go to portal row” ensures that it’s highlighted and visible.

The second suggestion, from Mike Beargie, uses a custom function called “ListIndex” (available from Brian Dunning’s site).  It’s a really concise one-liner:

portal_row_highlight2

The ListIndex CF just finds the position of the global id within the list of related SSN rec ids, and goes to that portal row, all in one script step.  Really neat, but, as Mike pointed out, it relies on the portal not being filtered.


Layout Tip – Tidy Pop-Ups On iOS

Pop-up menus in Filemaker Go are great, but have an annoying behaviour.  If, after selection from the menu, you tab automatically to a text field, the on-screen keyboard is displayed.  This is ugly.  You can, of course, remove the pop-up field from the tab order, but this has the effect of leaving the menu displayed after item selection – also ugly.  The solution is to have an OnObjectModify on the pop-up field, which just does a Commit Record.  This has the effect of removing the pop-up menu, which, combined with removing the field from the tab order, gives the calm, elegant behaviour that we seek!  (Thanks to Mike Mitchell on Filemaker Technet for pointing this out.)


Keeping Text Fields Tidy With Custom Functions

Having said in the previous post that I’m trying to use FileMaker’s own feature set wherever possible, there are some areas where it just ain’t good enough.

One such situation is in the formatting of text data entered by the user, especially name and address details.  For instance, if you want all names to held in “proper” case (e.g. “Jane Smythe”, rather than “JANE smythe”, “jane Smythe” or any other permutation), the “Proper” calculation function is available – you just need to make your field an auto-enter calc, with the calculation defined as “Proper (Self)“.

But this is very limited, and can actually create mistakes in data that has been correctly entered.  For example, if your user has carefully entered “John O’Shea”, she’ll be cheesed off when FileMaker changes it to “John O’shea”.  Likewise “Mary Macdonald”,  and “Bbc”.

For a more thorough treatment, I’ve had to look beyond FileMaker to a couple of Custom Functions, both found on Brian Dunning’s excellent site.   The CFs are:

  • Title, by Howard Schlossberg, which does a great job of putting capital letters where they should be, leaving them as caps where they should be, and making them lower case where appropriate.  It’s also quite adaptable, so you can add exceptions to be treated differently, etc.  It looks like Howard created it to format titles (of albums, books, etc.) properly, but it works just as well on names of people, organisations, etc.
  • SuperTrim, by Debi Fuchs, which removes leading and trailing spaces, tabs and carriage returns from the entered text.  Again, like FM’s native function (in this case, “Trim”), but better.

So, once the CFs are added to the application, it’s a straightforward job to define all appropriate text fields as auto-enter calcs with this calculation behind them:

SuperTrim (Title ( Self; “”))


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 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.