Trying to Detect Redirect for WebHTMLViewer

My client has a request that’s driving me crazy. We get a list of URL’s (varies greatly from user to user and from an automated process) and when they selected the URL form a list I just set the URL of the HTMLViewer to that URL. What they’d like to do is get any redirects and put that final URL into a label.

Example: if you attempt to load it should redirect to If I do that in the web HTMLViewer there’s no way to detect that it’s a redirect even though the URL is completely different.

I had the not so brilliant idea to use an HTTPSocket and look at either the HeadersReceived for the redirect information or in the PageReceived event but those appear to be worthless. The Status never showed up as a redirect and nor did the URL in the page received event changed.

I suspect this might be a problem with web. Looking for some additional ideas. Help!

In the HTMLViewer DocumentComplete you get the final URL so by comparing the URL you navigate to (also available in CancelLoad) and what completes, you know it has been redirected.

There are different ways of redirecting, but an HTTPSocket should be able to tell you if it is a 302, for instance.

Um…DocumentComplete is not available in a web project.

Sorry. Did not read the channel.

bump. any ideas to try?

In a regular page you can get the current URL inside the DOM with window.location.href.

My attemps to get the same information from the iframe DOM are not successful at this moment, but I believe it could be the way.

I’ll give it a shot.


You could certainly be up against iframe security. Once you hand an iframe a URL you can do very little with it unless you share its domain. Do you know if the type of event / notification you are looking for is available from an iframe (in the normal web world, not Xojo)?

Thanks for the reminder. I ended up getting HTTPSocket to work for what I needed.

Ultimately, the problem I was having was with the HTTPSecureSocket class I was trying to use. It seems that in web apps it wouldn’t fire the HeadersReceived event so I could never tell if the URL was being redirected. Once I switched to the non-secure version it worked just fine. It shouldn’t be any different but it was for whatever reason.