LiveCode Forums

Hello,

Is there a way to clear a Browser widget cache with LC Indy 9.04?

Thank you.

This comes up every half a year and never ever a team member lost a line about that. So probably they don't know themselves (convince me of the contrary).

URL:
Here is a good method to *refresh* the cache: https://www.mail-archive.com/use-liveco ... 82261.html

HTMLTEXT:
I have no problem with the htmltext of the widget.
The widget saves the current htmltext with its properties (in the stack) whenever you save the stack. And it loads it whenever you open the card containing the widget.
What I usually do is
= set the htmltext to empty on closeCard
= set it again on (pre)openCard.
Note.
The htmltext is not the *generated content* of the widget after you were doing some javascript in it. It is what you did set as htmltext.

Nice trick.
Thanks [-hh]

I'm having a pretty frustrating time with a browser widget, and the inability to properly force a full reload is, I think, at the heart of it.
I have a local HTML file that references an XML file, and that references a JavaScript file and a jpeg. This is a 360 VR player, and the file:/// path works for me in a browser (with local restrictions off), and it HAS worked for me in LiveCode.

But if I change the XML to look at a different jpeg it insists on still showing the first one. So change the HTML to refer to a different XML file, right? The XML file is being written on the fly so that's easy to manage. Except... it STILL insists on loading the old content. And no, I'm afraid adding ?something=12345 (actually [[the seconds]] merged, so it's different every time) to the end of the URL doesn't work at all for me. Is this perhaps related to it being a file:// path rather than http/https?

Rather than resorting to URL hacks we REALLY should have the ability to force flush the widget's cache by script, and insist that LiveCode reads everything from scratch. I'm actually really surprised that this capability doesn't exist.

k

Hi @thatkeith, I faced a similar problem and introducing a 500 millisecond delay (as suggested by Jackie in another post/bug report) between "clearing" the widget (setting the URL to empty) and loading the new URL seems to fix the issue.

This is the code I'm using
Probably there is no need to set both the URL and the HTMLText to empty, one of those would be enough but I haven't tested.

I say "seems to fix the issue" instead of "fixed the issue" because I haven't run enough tests but the preliminary experiences were all successful.

Hope it helps

Hi Simon – good to hear you've managed to tame this. I had tried something similar (500 milliseconds delay) although I'd done it after setting the URL and before showing the widget.

I've now started the script by clearing both the URL and the HTMLText of the browser widget (thanks for that suggestion), writing out the new XML, building the path to the HTML file plus the unique ?parameter=[[the seconds]] (merged, of course), then waiting for a full 2 seconds. No dice. The thing has been showing blank white since yesterday... but if I copy the URL from the widget and paste it in a browser it loads the page just fine.

This is REALLY frustrating! If the browser widget can get this locked into refusing to update itself how can it be considered truly fit for purpose?
This thing seriously needs some scripted cache-busting options at the very least.

k

I had a similar problem, the bug report with the workaround is here: https://quality.livecode.com/show_bug.cgi?id=22543

Ian's explanation near the end might give you some insight into how to fix the problem. My URLs didn't call nested references like yours do but the caching issues sound the same.

The bug report says this was fixed a few versions ago (9.6.0dp4). Is the fix not working?

FourthWorld wrote: ↑

Sat Oct 17, 2020 5:28 pm

The bug report says this was fixed a few versions ago (9.6.0dp4). Is the fix not working?

It worked for me, but the fix might not cover all scripting variations. I submitted my client project for examination but there may be other ways to trigger a similar problem.

Things have been complicated a bit by my new (very new) MacBook Pro dying on Tuesday and me switching temporarily to an older machine. I just realised I've been using 9.5.1 so I'll fix that pronto and see if it helps.

k