Just one thing to check... When deploying on FMGO I always insert an "Allow User Abort Off" at the beginning of the scripts. FMGO interprets any additional touch during a script as an attempt to cancel the script. While I have not seen this crash the app, it is possible that it might. While I am not always a fan of the "Allow User Abort Off" on the desktop, it is almost necessary in FMGO. Other things to consider... Does the web content require Flash, or a third party codec or plugin.
My personal experience with the Web Viewer is not very favorable. While it does have some interesting potential, I find it to be the most likely area to crash FM. In over 20 years of working with FM, "On the Mac" I could probably count the times it crashed on two hands (prior to FM12) Most of those times were when I used the Web Viewer. It may have been cleaned up more recently, but I generally use Open URL as an alternative.
Its not a user abort probem. Application becomes compeltly un-responsive but thinking wheel is spinning and is that why when you return after hours. web content is xml. webviwer is off screen because you can't see the xml anyway. its just there to grab with getlayoutobjectattribute function. Cant use Open URL because i need the xml in a field or variable for parsing later. btw work find on desktop.
Thanks for the thoughts.
FMGo does not support off-screen windows. The web viewer is attempting to display the XML and possibly it is unable to complete the rending.
Try using the "Insert from URL" script step to store the results in a field.
It's been a while since I've used the webviewer in GO to retrieve data from a server, but I seem to recall that there was a limitation whereby it was not possible to pull a pure XML document (i.e. XML, not HTML) through the webviewer. This definitely happened to me in version 11. I can't remember whether or not I tested this out in version 12.
I'm not asserting that this is the reason for the problem you've run into -- just a related piece of information to keep in mind.
I moved the web viewer on the layout. And it works as long as I am careful not to start it before the viewer finishes.
The idea to use insert from URL sound great I will try it. Sound like a more elegant solution
I have been able to get this xml data to load properly if I am carefull to have the viewer finish loading. It works great from desktop but I don't like that on iOS it could get a user stuck. I also tried to use insert from URL and that didn't work. Just gives me authentication errors.
I'm having a similar issue with a webviewer in my iOS solution, whereby I can set a field value using GetLayoutObjectAttribute (webviewer ; "content") on the desktop, but not using iOS on the iPad. The URL is generated using information from various fields in my solution, including a username and password. Interestingly, I have also noted that I could not authenticate with username and password to access a different URL on our intranet (again, only a problem when using iOS).
The "Insert from URL" script step solved the problem in my case, but it seems that there may be a limitation concerning the webviewer/webkit utilised in iOS for accessing a URL requiring authentication?