Since it appears that going out of the portal and back in gets the calendar to update, Is it possible to have the script , use go to Object to go out to an object outside of the portal then return to the correct row in the portal. Then finally update the value of the field? This may simulate the click outside of the portal and update your calendar.
Admittedly this is a kludge, but it shouldn't be much of performance hit if it works.
Thanks Bruce. I gave that a try but no luck. I also tried Go to Field, without any luck. I then tried Go to Object without a named object. No luck. I then tried Go to Record Next followed immediately by Go to Record Previous. No luck.
I also tried Set Web Viewer - Reload, Reset, URL - all three in tandem and combinations fo two. No luck.
Hi Daniel - what about adding another step to the calculation such as ...
If (not IsEmpty (Refresher) ;
Let ( ... and so on
Then within your script to refresh the webviewer, set a new value in the "Refresher" field belonging to the layout table occurrence. This might help to force refresh both the portal and webviewer calculation. Try creating the "Refresher" field as a non-global text field first.
I tried this and found that I had to set both the web address in the webviewer and the web address in the script step to the global field. In my test script I first put the URL into a global variable then used set field to update the global field. When I did this web viewer updated.
So my script looked like this
Set Web Viewe [Object Name: "wobj"; URL: test::wurl]
Thanks all. I found that on Windows it does work with a single click and on Mac (Lion) I need to double click. Not sure why the inconsistency, but that's how it works.
Sorry for opening such an old thread, but I have been looking for information on a webviewer issue when I came to see your post.
The double click isn't really a double click.
In fact, the first click sets the focus to the webviewer object, and the second click becomes a normal click in the page.
This is only the cas on Mac (even new versions like OS Sierre 10.12.3) with FileMaker Pro 14...
It is not the case on windows.
Also, it is not always the case...
It may depend how the click is triggered in the webpage, but I have not taked time to identify the source of this inconsistency between Windows and Mac versions of FileMaker.
Another wonderfully horrible inconsistency between both platforms is how the FileMaker zoom in handled...
One zooms the content of the webviewer while the other one just shows the content at 100% zoom.