We're designing a feature to run in FileMaker 18, hence no FMv19 JavaScript script features and are using Set Web Viewer to run some JavaScript in a web viewer.
Is it acknowledged standard behaviour for FileMaker Pro for Mac to allow Set Web Viewer to work when the viewer is either hidden in the grey developer area or hidden using 'Hidden Object When', but FileMaker Go will not?
This is looking like we've going to have to have the web viewer on the layout but out of view without actually hiding it to work with FileMaker Go.
Any suggestions or comments would be warmly welcomed.
Thanks
Andy
This is becoming very frustrating. In some cases putting the web viewer on the visible part of the layout resolves the problem. In others it doesn’t.
Trying to trace what is going on in FM Go when all is working OK in FM Pro is quite a challenge.
Hi @AndyHibbs ,
I did not comment when I first saw your post, because my experience with WebViewers and FMGo is very outdated. But seeing your last comment, I will mention that, in the early versions of FMGo, the nuances of WebViewers changed with almost every release, and so my takeaway was to be mindful about any time that I was straying from conventional use -- even including things like trying to make the WebViewer small and not really visible.
One of the things that I found, back then, was that certain versions of FMGo had some "smarts" built into the WebViewer, such that if the WebViewer was so small as to make FMGo think that no data from the page would be displayed, that FMGo actually would not process the code that I was loading into the WebViewer. I learned to have my "invisible" WebViewers not only match their background to the layout background, but also be just large enough to display a few letters of text (which would also blend into the background), so that FMGo would "take the webviewer seriously enough" to run its content.
To reiterate: This is ancient history as far as FMGo versions go. These were solutions running on generation 1 iPad and generation 1 iPad Mini.
4 Likes
Thanks Steve
There certainly isn’t much in terms of constructive analysis available, just plenty of trial and error, and hope to stumble on a solution.
So frustrating!
All the best
Andy
2 Likes
In case this helps anyone avoid the amount of wasted time we've lost on this.
To summarise:
We have a calling script that sets all necessary parameters for a generic subscript that eventually sets a web viewer with some JavaScript that includes calling back another FileMaker script to complete the process (this is pre-version 19, so we don't have the new JavaScript features). The name of the subscript is fed in to the calling script as a parameter.
Everything works absolutely fine in FileMaker Pro!
In FileMaker Go (19), when on a layout using a button to start the calling script, passing the callback script name as a parameter, everything works fine - providing the web viewer is present on the viewable layout and not hidden using 'hide object when'. This is not necessary for FileMaker Pro, which will work with the web viewer located in the grey offscreen area.
In FileMaker Go Running the same calling script, passing the same script parameter from another script fails to launch the callback script
After much trial, error and abandoned ideas it turns out a 'Refresh Window' (with both flushed options selected, didn't try it without) prior to setting the web viewer to the HTML/JavaScript solved the problem in FileMaker Go. We tried the Refresh Window in both the calling script and immediately before setting the web viewer and either option worked fine, therefore we left this in the generic script so as not to have to worry about it when using this again in the future.
I would estimate around 6 to 8 hours of lost development time due to the above and would like to publicly thank my wife Val for her suggestion to finally resolve the problem.
This is a danger point of stepping outside of FileMaker, with absolutely no tools available to help with the JavaScript or within FileMaker Go other than inserting custom dialogue messages at key points to understand where things are progressing to (or not as the case may be).
Regards
Andy
9 Likes
Thanks for posting the solution, Andy, and kudos to you and Val for getting to the bottom of it. I don't think I would have thought of applying a Refresh Window step.
We really didn’t have a choice Steve, we needed this to work as the client was grinding to a halt using the external API version during busy times of the day.
Thankfully, having a wife as co-director and ex Hypercard and FileMaker developer for over 30-years really optimises ‘2 heads are better than one’ benefits. We think very differently, which is a strength not a weakness. Our nephew has also worked for us for over 6 years and he’s also way ahead of us on various aspects of development - a true FileMaker family and you can guess the primary topic when we’re chatting.
2 Likes
Excel(lent) guess. But funnily enough not that much. However, the language can be blue at time (reference the above example) 
3 Likes
