When using WebDirect on an Android phone- or desktop sometimes when switching to a newlayout (via a scripted button)--
all formatting disappears-
see attached images.
anyone have ideas?
Thank you for your post.
When you saw "sometimes", can you be a little more specific. 75%? 50%?
Does this occur more often on an Android than on the Desktop?
Does this occur only with a specific layout or all layouts?
When the button script executes, what actions are taken?
Are there any script triggers assigned to the layout?
Any other information you can provide may be helpful in narrowing down the possible causes.
It happens almost every time after a handful of layout switching.
The only script trigger is to sort the list view on layout load.
No trigger on the form view.
Seems to occur on both Android and Desktop randomly.
Occurs on both list view and form view layouts.
Button only switches to other layout (single step)
Besides myself, Development and Testing would like to see your solution. I have sent you a private message with instructions where to send the file.
I received your file. Thank you.
I do not have an Android device available to me, but since you mentioned that the issue also occurs on "desktop", I focused my attention to Safari and Chrome under macOS Sierra 10.12.4 and Microsoft Internet Explorer and Chrome under Windows 7.
I am unable to replicate the issue with your file after switching layouts back and forth many times. Is there another set of steps you can provide that will reproduce the issue? Is there a specific browser and operating system you are using on the desktop machine? I will then focus on a similar setup as yours.
i am attaching a screenshot video to demonstrate when switching between layouts just using the
standard layout selector on webDirect.
The issue occurs at 1:49, then goes away again when switching away and back to that layout.
If you cannot reproduce-- what might be causing this issue and how can we diagnose/fix?
What operating system is running FileMaker Server 15.0.3?
What browser are you using? What version browser are you using? What operating system and version is running the browser?
Once I set up the same environment, I will try again.
this is the configuration:
Windows Server 2008 R2 SP1 Enterprise Edition
Requested Ram size = 8GB
Requested # CPUs = 4 (Multicore CPU recommended by FileMaker
Web publishing Server
Requested Ram size = 16 GB
Requested # CPUs = 12 core (recommended by FileMaker)
As for Chrome we just downloaded the latest version
Chrome Browser is running under Citrix xenapp virtual desktop for windows
Thank you for the information.
Although I don't have the Enterprise edition available to me at this time, I did install FileMaker Pro 15.0.3 on Windows Server 2008 R2.
I don't have access to Citrix, but I installed FileMaker Pro Advanced 15.0.3 on Windows 7 and Windows 10 machines. Google Chrome 57 is installed on both computers.
I am still unable to reproduce the issue. On the Windows 7 machine, I switched back and forth manually for 11 minutes without incident. On the Windows 10 machine, I switched back and forth closer to 20 minutes without incident.
Have you tried Chrome under Windows or Mac OS?
It is using the latest version of Chrome.
Unfortunately the file must be accessed via the Citrix Xenapp (using Chrome browser).
The client is New York City and they have strict protocols about how their data is accessed.
Both myself and the client experienced the problem both on Android and the Chrome browser.
If you cannot reproduce can you perhaps suggest a way of diagnosing the problem, what might be causing it or
how to solve?
I noticed the buttons on the layout also perform the same function. That is, on the "mobile . contacts . list" layout, the c_firstLast field is formatted as a button to execute the script step: Go to Layout [ "mobile . contacts . form . view" ], which would be the same as manually selecting the layout.
Also, on the "mobile.contact.form.view" layout, the "List" button in the upper left corner executes the script step:
Go to Layout [ "mobile . contact . list" ]
... which would be the same as manually selecting the original layout.
These are definitely easier to access as you simply click an object rather than dragging down the pop-up and selecting the layout.
I only spent 5 minutes on both Windows 7 and Windows 10, and I probably switched layouts the same amount as if using 10+ minutes. Are you getting the same results using this method?
If so, try using a Script instead of a script step, and include a Refresh Object or Refresh Window after switching to the appropriate layout.
yes-- i was trying to demonstrate that the scripts are not the problem--
that's why i used the layout selector instead of the buttons.
i will try using refresh on the scripts and see if it helps.
Tried the refresh on the go to layout script.
when you navigate away and back it usually goes back to normal for a while
then a few navigations later-- same issue.
not sure what else to try....or why this is happening.
I'm not sure what else to try. I have been unsuccessful trying to reproduce the issue on both Windows and Mac computers.
Your video appears to be a sporadic refresh issue, so that is the reason why I suggested a Refresh Window script step.
Again, are you able to reproduce the issue with Chrome under either Mac OS or Windows?
Yes- it is running the latest version of Chrome under the Citrix xenapp.
I tried one thing (an idea from another forum)--
made sure all layout objects were saved to the theme.
seems to help somewhat--
only every 10-15x layout changes does the issue occur- then when changing again and back again
it goes away.
still really want to figure out how to diagnose/fix.
Having another fresh pair of eyes look at your entire thread, the first thing noticed was the not secure https: connection in the movie file. Have you tried disabling SSL and access via http:? If that works, then enable SSL and make sure your certificate is valid and configured correctly. If you are using the FileMaker default certificate, then do not use SSL.
The Client fixed the SSL error and it seems that the problem has disappeared.
So you can close this ticket for now.
Retrieving data ...