FileMaker Go Bug?
FileMaker Go Bug?
3/8/18 UPDATE
It turns out to be the real bug:
Thank you for your posts and movie file. I am able to reproduce the issue with FileMaker Go 16.0.4 under iOS 11.2.6 using an iPad Pro. I have sent all information, including a sample file, to our Development and Testing departments for review. When I receive any feedback, I will let you know.
TSGal
FileMaker, Inc.
Hopefully, it will be patched soon.
I am working with another developer on a big rollout for a primarily iPad based solution. We are using sliding panels as a major interface feature. In the development process, we discovered a FileMaker Go Bug.
The app is feature packed and has multiple sliding panels on each major interface page. On some layouts, up to seven sliding panels are stacked on top of each other. While this results in a more complex development environment, the resulting user experience (UX) is impressive and has a reduced learning curve.
And it all works well on Mac’s and PC’s.
Using FileMaker Client on a Mac or a PC is not a problem. When we programmatically activate a sliding panel, that panel assumes “Active Focus”, meaning the panels essentially drop behind the Active Focus panel despite their relative position in the stack.
For example, activating the 7th (lowest) panel in the stack using the “Go to Object” command essentially brings that sliding panel to the top of the stack.
Once on top, all functionality you would expect does work: filed access, scrolling, popovers, button access, etc. But…
Portal Scrolling does not work FileMaker Go
On FileMaker Go, however, there is a major problem. Calling the 7th panel and giving it Active Focus on FileMaker Go works for all functions save one: scrolling a portal. Watch this short video to see the bug in action:
Steps we have taken to try to squash the bug:
We reviewed all of the Window script steps: Since the panels are placed on a Window, those commands were not effective.
We also tried various Navigation commands, and I suspect we could build a script to go to a record in a portal and force a scroll, but that is clunky and not intuitive to the user.
The only thing we have found that works is to hide the slider using “Hide Object When”. The problem there is the logic it takes to properly hide up to 7 different sliders using conditional logic. It can be done, but only after all design considerations have been locked down. Adding any new features sends us back to the logic maze with plenty of testing to ensure all works OK.
In the hope that there is a work around we have not yet discovered, I am posting this on various forums and with FileMaker, and also posting here on my blog.
Denis
March 5, 2018 @ 9:51 am
Couldn’t you just make the parent 5 sheets wide rather than with an two on top of each other?
Don Clark
March 5, 2018 @ 2:26 pm
We have several layouts with multiples already developed and did not discover the problem until later. Is an issue now, but not unbearable compared to redoing all the scripting and logic.
Thanks for your suggestion, though.
J Willing
March 8, 2018 @ 2:42 am
So you want to scroll a portal that is underneath another slide panel? Why would the top panel not always contain the object you are interacting with?
J Willing
March 8, 2018 @ 2:42 am
I just tested and by putting the portal on top of the inner panel, it scrolls fine. But It looks like you might be going for something different.
Don Clark
March 8, 2018 @ 6:50 am
It turns out to be a real bug:
Thank you for your posts and movie file. I am able to reproduce the issue with FileMaker Go 16.0.4 under iOS 11.2.6 using an iPad Pro. I have sent all information, including a sample file, to our Development and Testing departments for review. When I receive any feedback, I will let you know.
TSGal
FileMaker, Inc.
Joshua Willing
March 8, 2018 @ 12:20 pm
Nice find!
Don Clark
March 8, 2018 @ 6:51 am
See my reply in your previous post – hopefully this will be patched soon.