AnsweredAssumed Answered

The 'next' and 'previous' buttons of FileMaker Go cannot be hidden

Question asked by codecruncher on Jul 4, 2012
Latest reply on Sep 19, 2012 by codecruncher

Summary

The 'next' and 'previous' buttons of FileMaker Go cannot be hidden

Product

FileMaker Go

Version

Go_iPad 12.0.3

Operating system version

iOS

Description of the issue

The 'next' and 'previous' buttons of FileMaker Go cannot be hidden


There is no setting or script command to prevent the 'next' and 'previous' buttons of the bottom navigation bar to slide up and block part of the layout of a FileMaker solution. Other users have reported the issue as well and the official reason for this behavior is that FileMaker Go cannot determine wether an external keyboard is connected.

The problem is that the navigation bar slides over the layout to block important buttons instead of adjusting the size of the layout whenever a window is maximized.

The 'next' and 'previous' buttons even show up when the layout doesn't have a specific tab order. They are simply inactive. This is very confusing to the end user who only sees them appear on occasion to block the layout without rhyme or reason.

To my own amusement I actually thought they were undo and redo buttons at first until I scouted the existing bug reports. I have never felt the urge to go backwards in the tab order which is why I didn't realize that the 'previous' button could be related to the tab order in the first place.

Why is there is no global option to hide the tab keys whenever the user chooses not to use an external keyboard? The big 'next' button of the onscreen keyboard works far better than the tiny next button on top the onscreen keyboard. The iPad was designed to be used via the touchscreen and only a small percentage of users will actually purchase an external keyboard.

I came up with a partial solution with a script that would select a specific graphic object with the ‘Go to Object’ script step and then execute a commit Record/Request script step.

Of course the 'next' and 'previous' buttons also appear whenever you scroll through a portal. Since the portal is not actually selected there is no way to hide the buttons after scrolling.

The buttons also appear when selecting a value list suggesting to the unsuspecting user that he can go to the 'previous' and 'next' value in the list which of course is not possible.

A typical user might ask:

What do the 'next' and 'previous' buttons do?
How do I make them disappear?
How can I access the menu item underneath?
Am I supposed to use them to go through the ‘next’ and the ‘previous’ page of the selected portal?
Are they there to let me select the 'next' and the 'previous' item in a list?
Why would any buttons slide up if they do not have a function?
Are these buttons important?
Am I doing something wrong?
Does the developer even know about this?
Should I file a bug report?
Should I simply close this buggy application and play Angry Birds?

I can only cross my fingers that the current behavior will be changed. These buttons simply don’t make sense. Even if you have a keyboard attached to your iPad you can only use the ‘previous’ and ‘next’ buttons if the layout has a tab order. Of course the buttons will show up even when a layout doesn’t have a tab order and a user with a keyboard might ask:

Why can’t I go to the next field?
Is my iPad screen broken?
Will it help if I unplug my keyboard briefly?
Should I clean the screen with rubbing alcohol?
Is this iPad still under warranty?
Is this only a software bug?
Does the developer even know about this?
Should I file a bug report?
Should I simply close this buggy application and play Angry Birds?

Expected result

There is a simply global setting to disable the 'previous' and 'next' buttons.

Actual result

The confused user will end up closing your application to play Angry Birds.

Workaround

None

Outcomes