Hello All!
I'm back to a bit of VFP programming and tasked with integrating an intranet site within a legacy VFP app.
I need to capture when the site opens a new window and perform some processing. This appears to be possible by using the NewWindow3 event. All good so far...
The issue is I don't want the new window to actually open. I have tried setting the 'cancel' parameter to .T. and 1 as documented here: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa768288(v%3Dvs.85) to no avail.
Anyone got any ideas?
Thanks.
You probably shouldn't be using the IE specific APIs - instead use the actual DOM events and make sure your Web browser control renders in Edge mode.
Actually I think the better way is to detect the navigation in FoxPro using BeforeNavigate2
in the WebBrowser control and detect navigation checking for the targetFramename. If it's not blank or null, a new window navigation is happening and you can cancel there.
+++ Rick ---
Hi Rick,
Thanks for your message - much appreciated.
I had already read your article Specifying IE Version with the Web Browser control which is very, very useful.
I had tried to use BeforeNavigate2
however I need to capture the content of the new page locally (it's actually a PDF document) but not display it - just print it to the default printer. Currently I'm using a real bare-bones version of your HTTPGet
function within wwIPStuff (the code on pages 228/229 of Internet Applications with Visual FoxPro 6.0) because I own a copy of that book but I'm not sure if I can use wwIPStuff / West Wind Internet & Client Tools at the company I'm now at. You probably won't remember but we met at the Double Impact Tour in London many years ago and I got a copy from there.
Back to the original question for a moment (and out of interest), is there a way to use the cancel
(out) parameter exposed in the NewWindow3
method from within VFP? Obviously CANCEL
is a reserved word in VFP so I tried changing the parameter name to bcancel
also.
Anyway, I'm sure there's probably a better way of doing this so open to options...
Thanks again.
BeforeNavigate2
should capture the URL that you are about to open as well as the data so you should be able to intercept the entire request that is about to be made, use wwHttp to download the URL and then print or whatever...
I use this everywhere so I'm pretty sure this should work, unless the code in question doesn't use a link. I have never used NewWindow3
so I don't know if that works as you expect and actually fires on a window.open()
operation.
+++ Rick ---
Hmmm... Inspecting the URL and the PDISP object (LocationName / LocationURL) in BeforeNavigate2
shows me the existing URL rather than the new one.
I'm guessing it must be something do to with the way the internal site has been written because if I test against www.bbc.co.uk for example the URL and PDISP objects show the URL being navigated to.
I've asked the web developer in question to not launch a new window to get around the first issue. I can capture the new URL in NavigateComplete2
and having captured the original URL (in BeforeNavigate2
), call Navigate2
to flip back again when I know the site is going to a specific URL.
It works but it's clunky and now I'm curious to know what is being done in the website code. It's in vb.net so I'd rather not go there!
Thanks again for taking the time to respond.
Well most likely it's the difference between a link navigation (<a href="url">
) vs a window navigation (window.open('url')
). That might behavior differences. It is surprising though that before navigate fires but doens't return the navigated URL.
Nothing to do with the .NET backend code most likely - but the client side script code on how they deal with the link navigation.
+++ Rick ---
OK, long story shot I managed to get the web developer to change the website code so that BeforeNavigate2
detects the URL we are navigating to.
I'm sure I tried setting cancel = .T.
before and it didn't work but referring back to Internet Applications with VFP 6.0 that's what you did, and what do you know? It works!
I'm a happy man.
Thanks for all your help, excellent book, and website content.
Keep in mind that the book is nearly 20 years old 😃 So a number of things have changed especially when it comes to DOM behavior (although not the actual Web Browser control)...
+++ Rick ---
(c) 1999. "And don't ever let a Dilbert-head tell you that it can't be done with the Fox!!!"
😃
A lot has changed in nearly 20 years 😃
Just because you can, doesn't mean you should...
It always amazes me what we have been able to accomplish with a tool abandoned more than 10 years ago. I've seen so many amazing FoxPro apps (even relatively recently) that you would never know are FoxPro unless somebody told you. It just shows you that the tools are only a part of the journey to a great product - the ideas and implementations are the key.
But - that's not to say there aren't other better solutions available today... The tool is after all just a tool and not the end product.
+++ Rick ---