Hiding tab buttons
Pretty simple question I think, just wondered if it's possible to hide or disable the tab "next" and "previous" button bar on FM Go?
Thank you for your post.
At this time, you cannot hide the "Previous" and "Next" buttons. You can disable the buttons if you remove the tab order, since "Previous" and "Next" will then be unable to move to another field.
Can you provide an example why you want this removed?
I'm just trying to stop any possible way of the user being able to slide the page up or down? Already using hide status bar which works but when tab buttons are showing it allows it again.
I'm having a similar experience with one of my solutions.
Basically I'm serving a one page survey. The user has to check off a number of radio buttons, one field for every question. Every time they fill in a radio button the status bar with "Previous", "Next", Record Slider, "+/-", and find button appears at the bottom of the screen.
This causes two issues:
1. It allows the user to accidentally change to a previous record which could mess up the data.
2. It reduces the viewing window so now the page scrolls up/down when it doesn't need to.
I notice that this behaviour only occurs in FMG iPad, not FMG iphone.
If there was a way to suppress this it would be fantastic.
Exactly the same problems I'm experiencing Chris!, hope some has a workaround.
I have found a half-way solution. By running a script with step "Show/Hide Status Area [Lock; Hide]" I still get the bar appearing at the bottom of the page, but now it only has the "previous" and "Next" buttons on it, no record slider and other buttons.
If you tap on a non-field or button object this bar will disappear. When you tap on a field it will re-appear - but again without the troublesome extra buttons. Hitting the "Next" and "Previous" buttons does still move from one field to the next/prev which could produce some confused clients but at least they are stuck on the same record.
Even when I shorten the layout size to include the 44 pixels-or-so of the status bar that appears it still scrolls as though there is a white band along the bottom of the page. Arrrg.
Best solution would still be for FMGiPad to react like FMGiPhone and not have this status bar appear, or at least be able to properly suppress it.
Just saw that this was explained by FM.
Know bugs list:
Looks like they don't think it's a problem because some users might be entering data on an external keyboard (which legitimately can't be detected).
I still contend that there should be a way to lock the bottom status bar in "hide" - given that the software is designed to work on a touch computer.
Here's to hoping for 1.2.2...
The problem I have with the functionality of the navigation bar (with the Prev and Next buttons) is that often (but not always) when it appears it ‘pushes up’ everything up from the bottom 44 pixels and we lose our navigation area at the top of the screen.
But, at other times it will ‘drop in’ on top of the layout (which I think is the way it should appear all the time) and not push everything up. We have spent a lot of time determining when it does this and when it does not – and it is impossible for us to work around.
I understand FileMaker’s reasoning why this bar is necessary – but I don’t understand why it manifests itself in different ways at different times.
Finally, I want to stress that the ‘push up’ effect that moves your entire layout up 44 pixels is major problem for user interaction. FMGo already can ‘drop’ the navigation bar on top of the screen – it does that in some instances – it would be great if it could do it all the time.
Can anyone at FileMaker explain these differences and/or comment on our findings?
Facility Wizard Software
Different ways at different times is probably the result of having different groups work on different areas with no central control. Witness the various designs of Filemakers own Dialogs and how some scroll, some don't, some are too darn small and almost none remember your preferred adjustments. There seems to be no central committe for approving of designs and setting standards... And, sadly, no actual users with final approval or over riding authority.
And of course there is the usual problem of get it out the door and we'll fix it later. All software is beta and the buyers are the beta testers. Some of my files have been extreme examples. :)
After all, this is only the first version so grin and bear it. And, as any old timer knows, the motto of the software industry is "If it works, we'll fix it."
Late to the party, per usual. I'm dealing with this now and I'm wondering if anybody has a better solution yet. I am currently putting a script on fields' onObjectModify trigger that simply commits the record because I read that the prev/next bar shows up when record is uncommitted. This seems to be working, but it's tedious to go through the entire solution and determine when/where I can safely apply this. I thought I read somewhere that removing the tab order of a layout would similarly inhibit the prev/next bar, but I haven't found that to be the case in my solution. Could be something else I'm doing.
If anyone has a better solution, I'd love a hint, otherwise here's mine ^
This doesn't solve all the issues mentioned here, but one way to keep "previous" and "next" from taking the user to a different record is to limit the found set to a single record.
It is also sometimes worth the effort to pull the data into a set of global fields for editing and then save them back to the original record (or create a new record) when a user taps save. Since the fields are global, it doesn't matter much which record is current and you can even base the layout on a completely different table.
Thanks Phil, but maybe I'm on the wrong thread. The prev/next bar I'm dealing with is for tab order, not navigating records.. And again, committing the record via a trigger is working for me, but it's a huge pain. All just because I hate that little prev/next bar popping up and covering up my soft buttons..
Sorry, but I just starting playing with an iPad hours ago having used a phone up to this point. I'd misread that previous, next reference to meaning previous or next record rather than previous or next field. I can see with a little trial an error that I am mistaken.
Retrieving data ...