Getting occasional "404: File Not Found" in WebHTMLViewer

[Tim_Parnell]

@437139:@Thomas Tempelmann

Do you know for sure that Xojo’s LoadPage writes a file internally? Probably generating a WebFile?

Yes, you can see it’s writing a file. Use browser debugging tools to view the DOM. You can see that the iframe loads a url and not the source directly. Browser debugging tools are a huge part of effectively writing a web app. I wouldn’t know about whether it’s a WebFile or not though.

[Greg_O_Lone]

@437305:@Tim Parnell

I wouldn’t know about whether it’s a WebFile or not though.

It is a WebFile behind the scenes.

[Greg_O_Lone]

@437305:@Tim Parnell

Use browser debugging tools to view the DOM. You can see that the iframe loads a url and not the source directly.

FWIW, this is changing in the new web framework. When you specify raw html, we will render just a div and place your html in it. URLs will still be rendered in a sandboxed iFrame.

[Richard_Duke]

[quote=437130:@Thomas Tempelmann]Yes, I meant WebHTMLViewer

And no, there is no WebFile. I already explained that I just pass a string to LoadPage. THERE IS NO FILE on my end.

But if everyone thinks it’s a problem with the file, and me no having control over any file, it must be the WebHTMLViewer’s fault, right? I.e. a bug?[/quote]

i recently do something like that … putting a string into the webhtmlviewer with 2019r1 without problem. the only problem i have instead is images is not showing up webhtmlviewer and these images is just located next to the web app…

[Greg_O_Lone]

@437316:@Richard Duke

i recently do something like that … putting a string into the webhtmlviewer with 2019r1 without problem. the only problem i have instead is images is not showing up webhtmlviewer and these images is just located next to the web app…

Unless you’re using absolute urls for those images, either through Apache/IIS, HandleUrl or HandleSpecialUrl or other WebFiles, images must be relative to the html in the html viewer which can’t be done in the current framework.