views:

158

answers:

2

We're in the unfortunate position of having to use a JavaScript control intended for a web page inside our Windows desktop application. To accomplish this, we host Internet Explorer inside our application and tell it to navigate to a local web page. We then get the IDispatch interface of the script engine and use it to interact with the control. The web page looks something like this:

<html>
  <head>
    <script src="third party website url" type="text/javascript"></script>
  </head>
  <body onload="OurApp.OnLoad()">
  </body>
</html>

(I've omitted some tags and attributes for clarity.) We add the "OurApp" object to the script engine's namespace. It's an IDispatch interface that allows the script to call back into our application. In our application's OnLoad() method, we construct various JavaScript objects defined by the control.

Problem: In 99% of cases, this set-up works great. Unfortunately, on some customer machines, our OnLoad() method can't find any of the expected methods in the script engine. It's like the JavaScript from the third party's website either didn't load or wasn't allowed to run. For many customers, we've resolved the issue by changing the security settings in Internet Explorer. But now we have some customers where the security settings appear to be correct, but we're still encountering the problem.

As an added wrinkle, if I create a web page as above and have the customer open it on his machine, he gets a popup bar asking him to authorize the active content and then everything works fine once he agrees. (In this page I've replaced the OurApp.OnLoad() call with some JavaScript that does the same thing.) This is the same behaviour I get on my machine, but our application works fine here. We aren't getting any error messages at all on the customer's machine (though maybe we're just not looking in the right places).

So, I'm stumped. Any thoughts or suggestions would be greately appreciated.

Update We've finally managed to resolve the problem. The issue was that we were passing an unsupported locale to the third party website. In this case, they were returning as an empty script instead of a close match or reasonable default.

+2  A: 

It's hard to be 100% sure what the problem is, but if I were to guess I would say it probably has to do with the customers IT departments locking down their machines with certain security policies, proxies, things of that nature. Have you discussed these issues with the customers IT department who are experiencing this problem?

Are you connecting to the remote page on a different port than :80 in the hosted IE control? I don't know much but the IE COM but is it possible to get errors, warnings, things of that nature programatically?

tj111
Yes, but they haven't been helpful. What I find particularly strange is that Internet Explorer can display the local page just fine, but the hosted Internet Explorer control cannot (but only on their machine).
Peter Ruderman
+2  A: 

You might want to implement your own security manager:

http://msdn.microsoft.com/en-us/library/ms537182(VS.85).aspx

Joeri Sebrechts
This looks very promising indeed. I'll let you know how it turns out.
Peter Ruderman
Well, I've implemented the ISecurityManager interface on our control site but still no joy. This does solve the issue where the Internet Explorer security settings are too prohibitive, which is useful for us. It will certainly eliminate support calls, so thanks for this. Unfortunately, our odd-ball customer is still having problems, which I guess must be the same symptom but a different cause. Anyway, I'll keep at it. Thanks again.
Peter Ruderman
The problem turned out to be a simple localization issue, but this really is a useful answer, so I'll mark it as accepted.
Peter Ruderman
The irony is that I haven't actually implemented it myself. Guess I'll have to block off some time for this...
Joeri Sebrechts