Sweet Scrolling in FileMaker Go 12

By Daniel Wood, 14 May 2012


Portal scrolling has always been a bit of a struggle in FileMaker Go up until the release of version 12. This article outlines some of the changes to portal scrolling in FileMaker Go 12 and we give a couple of examples how it can be set-up to give a very nice native-application look and feel. We also cover field scrolling.

Getting that Native-App look

If you look at any regular application on the iPhone or iPad you'll notice they all have very similar looking scrolling. This is typified by a thin grey bar to give a visual cue as to where the scroll position is - yet there is no actual scrollbar present.

sweetscrolling 1


sweetscrolling 2

In these applications the scroll indicator is close up to the right edge of the screen. You'll notice it can even slightly overlay some of the contents, as if the scroll is floating on top of everything else. This is what we are going to try and replicate for our FileMaker Go layout for iPhone.

Our iPhone layout design

So below we have a layout that we have designed to be used on an iPhone running FileMaker Go 12. This layout mostly contains a portal and as you can see in the image, we too have a little grey scroll indicator up to the right edge of screen.

sweetscrolling 3

You may be asking yourself why we didn't just use a list-view layout as opposed to a portal - surely that would have been easier. There are a couple of reasons why we chose not to:

  • We do not wish for our context to be that of the portal (or a list-view layout).
  • Portals have a tendency to render much faster than records in list-view. This means they feel much more like a faster native application, and we don't see so much blocky rendering happening.
  • Portals in FileMaker Go 12 no longer require to be clicked into before you can begin scrolling which was the case in FileMaker Go 11. This means they are actually usable now!
  • With a portal you get a nice left-edge of the screen without the list-view thin bar you get to indicate current record.

If we look at the layout in layout mode, you can see how this effect has been achieved.

sweetscrolling 4

What we have done is to simply place the visible scroll-bar portion of the portal off the right edge of the layout. This means the visual scroll bar never appears on-screen but the grey scroll indicator does given that it is appearing to the left of the scroll bar - the area of which is still on screen.

It is a very strange thing that portals in FileMaker Go 12 should even render with a scrollbar at all - they are completely useless and do not actually serve any functional purpose as we shall see later. Good thing we can now hide things off the edge of the screen!

What about scrolling within a layout?

Scrolling when the portal extends to the edge of the layout is fine because we can simply hide the scroll bar off the edge of the layout. But what if we have a portal we want to scroll that is contained within the layout too far from the edge to be hidden?

sweetscrolling 5

Let's consider the screen above. In this case we have a portal that is not touching the edge of the layout. Never fear! We can still achieve the same desired effect with a little jiggery pokery.

But first...

Before we show how this effect can be achieved let's investigate why a regular portal is a bad idea to be used on-screen in FileMaker Go 12 for scrolling.

sweetscrolling 6


 sweetscrolling 7

Here we have a typical portal displayed within the layout shown in both browse mode and layout mode. We have some rounded corners on the portal because the desired effect is to show a rounded white box on the screen with the records within. The scrollbar is clearly visible for all to see.

Now, what do you suppose would happen if the user began to run their finger up the portal to scroll? Well, it's a scrollbar so you may expect it to look how it might in FileMaker Pro, surely.

sweetscrolling 8

As soon as the user begins to scroll, the scroll bar disappears entirely! This leaves no right edge to the portal which means it no longer has rounded right edges. The grey scroll indicator you can see is still present aligned to the left of where the scroll bar used to be.

sweetscrolling 9

In this above picture, the user has stopped scrolling, but the scroll bar is still nowhere to be seen. In fact, the only time the scroll bar appears is when the user is not in the portal. It can be made to reappear when the user clicks elsewhere on the layout - but when it appears it is simply a scrollbar with no actual use. We should just get rid of it entirely!

Hide the scrollbar by covering it up

We've all done this in FileMaker development at some point or another - cover up layout objects with other objects. Fortunately in FileMaker Go 12, if you cover just the scroll bar part of a portal with another object, the scroll bar will never appear, or jump in front of it's overlaying object, so it is quite simple to hide them.

sweetscrolling 10

Here we have placed a graphic over top of the scrollbar. It should be noted here that because the portal scrollbar constitutes the right-edge of the portal, then with it disappearing we no longer have a rounded right edge to display. To remedy this, we have made the portal transparent, and placed a rounded rectangle beneath the portal instead.

sweetscrolling 11

It does not matter where the portal scroll bar is positioned so long as it can be overlaid. In this case we wanted to get the scroll indicator positioned in such a place that means the scroll bar is part-on and part-off the layout. This is no problem however.

Scrolling of text fields

The next challenge we encountered with scrolling in FileMaker Go 12 came when we tried to scroll a text field on the layout. In FileMaker Pro 12 if you want to scroll a text field you put a scrollbar on it, click into the field, and then begin scrolling. Unfortunately it's not so easy in FileMaker Go 12.

sweetscrolling 12

Here we have a field on the layout. Note we have no scrollbar. The reason is that once the user is clicked in the field, they can scroll whether there is a scrollbar or not, so it is again kind of a redundant artifact to be showing on a field.

sweetscrolling 13

So, here is the field in browse mode showing lots of text, too much to see on screen at once, so we really want to be able to scroll. Let's try clicking into the field ala FileMaker Pro 12.

sweetscrolling 14

Problem! in FileMaker Go 12 when you click into a field, it automatically reveals the keyboard in anticipation for input. It does not know that we merely want to view and scroll the information in the field, not edit it! We don't want to show the keyboard every time we want to scroll, nor do we want to have to click into the field to begin scrolling. It would be nice if it performs like portals do.

Web viewers to the rescue

One solution to this issue we found was to use web viewers instead. In FileMaker Go 12, the web viewers exhibit a nice scrolling experience much the same as portals. Also they do not reveal the keyboard because there is no field to click into.

The one difference between web viewers and portals however is that a web viewer must be clicked into and given focus before it will scroll, it does not register scrolling automatically. We can overcome this however through using some script triggers, more on this below.

sweetscrolling 15


sweetscrolling 16

In order to display the fields contents we are using a Data URL. This allows us to render text in the field directly via the web viewer without the need for plugins - which are not compatible with FileMaker Go anyway.

sweetscrolling 17

The end result is quite nice. To overcome the fact the web viewer has to be in focus to be scrolled, we are ensuring that when we go to the above particular screen, we go directly to the web viewer through a Go to Object script step. By arriving at this screen directly in the web viewer, the user can begin scrolling right away.

In the picture above we have used data:text/plain as our data URL scheme which gives the font in courier. This lets the text automatically wrap itself to the edge of the web viewer so we have no side-scrolling required to view all of the text. We are sure there are always to alter the font and retain this behavior but have not investigated this further.

Because in this solution nothing is editable, the user has no reason to leave the web viewer unless they choose to via one of the navigation buttons. To keep the scroll alive, we put a simple little script trigger on the web viewer for the onObjectExit condition.

sweetscrolling 18

sweetscrolling 19

Whenever the user attempts to leave the web viewer, they will only succeed in doing so if the parameter to the script is non-empty. Because we are passing the current script name as a parameter - it means the user will only be able to exit the web viewer if navigating away from it via script. If they manually attempt to click outside of the web viewer - e.g. on the layout - then this will fail and they will be kept in the web viewer. Because all of our navigation is from scripts, this ensures that when a script tries to navigate the user away from this screen it will succeed in doing so.

Just a note about web viewers in FileMaker Go 12

In building the database on which this article is based we encountered a number of rendering issues with the web viewers in FileMaker Go 12. Often the web viewers simply fail to render anything, and are displayed as a black box. Other times they part-render insomuch as they display as a blank white box instead of black! It is only about 1/2 the time that they actually work properly and render the contents of the data URL.

We have also noticed other issues with web viewers in FileMaker Pro 12 Advanced which are bugs, and we have been submitting these to FileMaker in the hopes they will be resolved in an upcoming patch. So fingers crossed the reliability of the web viewer improves in future releases so that this technique becomes 100% reliable :)

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article, and to let you experiment with this solution in both FileMaker Pro and FileMaker Go.

Download Example File

Something to say? Post a comment...


  • rthompson 28/05/2015 9:57am (1 year ago)

    Hello again,
    I thought I'd share that I've finally resolved the issue I raised in my previous comment/question. The issue was: web viewer in FMGo 'bounces' when scrolling vertically (attempting to scroll after reaching either the top or bottom), regardless of css behind it (overflow:hidden on body does not help).

    I have found that, if you are willing to take on the responsibility of managing div positions, then using javascript you can 'mute' the native swiping action which will prohibit the webviewer from doing the annoying bounce thing (especially annoying if you have div elements that themselves scroll). So, I have something like this:
    function init(){
    // called on window.onload
    document.getElementById("contentWrapper").addEventListener('touchstart', muteTouch, false);
    function muteTouch(evt) {

    and then i have event listeners on the document itself which send me the swipe information needed to update my div positions giving a page-flipping-like effect when user swipes.. which I actually prefer to a continuous scroll..

  • rthompson 30/01/2015 10:28am (2 years ago)

    I'm doing something similar and it's working beautifully. One thing that bothers me though is that the webviewer 'bounces' vertically when scrolled. I have css in place that should dictate that there is no vertical scrolling, but still the webviewer seems to try to scroll and it results in a 'bounce'. Am I missing a simple solution to this? I'm not seeing anything on the subject.. Thanks!

  • Damian 14/05/2013 4:11am (3 years ago)

    You can hide the scroll bar through the CSS in a layouts theme, in the filemaker package go to the themes folder here:
    FileMaker Pro/Resources/Themes/WhatEverThemeYouWant/
    (note: you will have to open the filemaker package, Windows I am not sure what you do :-) )
    Within here find the portal:normal .contents and set the right to 0, do the same again to the portal:normal .scrollbartrack and bobs your uncle....

    Here is what your CSS should look like:

    portal:normal .contents {
    position: absolute;
    left: 0pt;
    top: 0pt;
    bottom: 0pt;
    right: 0pt;
    box-sizing: border-box;
    portal:normal .scrollbar_track {
    position: absolute;
    top: 0pt;
    bottom: 0pt;
    right: 0pt;
    width: 0pt;
    box-sizing: border-box;

    Hacks like this come with the usual warnings; you may need a grown up to help you using scissors.

  • Daniel Wood 09/08/2012 10:45am (4 years ago)

    Hi Christopher,
    The nav icons and a lot of the graphics for the solution are from Matt Petrowsky's Theme Studio which is a great resource.

    To get rid of the top toolbar in FMGo the solution is opened in Kiosk mode. So the database is set to automatically login as a non-full access user and the solution itself has been changed via developer utilities in FMPro Advanced to open in kiosk for non-admins.

    When this is done the database will open without the top toolbar which is really nice if you want to make a 'tight' FMGo database that has no real acknowledgement of the fact it is FileMaker

  • Christopher Gauthier 08/08/2012 7:42am (4 years ago)

    Also curious how you got rid of the top tool bar in your FMGo app. I can't find any docs on how to do that. Good lookin' app. Thanks.

  • Chris Gauthier 08/08/2012 1:47am (4 years ago)

    Are those nice Nav buttons ('close', 'results', 'all contacts'...) publicly available somewhere - or did you create them and would be willing to share?

  • Bob Carlson 10/06/2012 3:43pm (4 years ago)

    Nevermind. Spoke too soon. I just needed to lock my resizing in all four directions.

  • Bob Carlson 10/06/2012 2:53pm (4 years ago)

    Really cool ideas here. Any suggestions on how to handle screen orientation with portals on iOS? I developed a portal to fill the screen in portrait mode but as soon as the device is rotated you can't access the items at the bottom of the portal.

  • Doug Alder 25/05/2012 5:18am (4 years ago)

    Great article. Minor typo:

    "We are sure there are aways to alter the font and retain this behavior but have not investigated this further"

    should be:

    "We are sure there are ways to alter the font and retain this behavior but have not investigated this further"

  • Charlie Bailey 17/05/2012 1:18am (4 years ago)

    Nice article (as always) Daniel. This is a sweet technique.

RSS feed for comments on this page | RSS feed for all comments

Categories(show all)