I had an MS Access database which had been in place for over a year and that was working just fine. One day, at the beginning of October 2013, my client informed me that they had recently started receiving a Scripting error (see the image below) every time the form displayed a map (Google Maps) of an address, any address.
At first, I assumed it was a Google glitch and figured we’d give the Google team a chance to rectify whatever the issue was. That said, days, weeks, went by and the problem remained. So it was time to do some more digging.
During the testing phase. I was able to confirm that using the same URL directly in a web browser (IE, FireFox, Chrome) all displayed just fine without any errors. Furthermore, the error itself did not occur on every machine. This leads me to seriously believe it has to do with some windows update that is applied to certain computers and not others. If it were truly a Google issue, it would be generalized, which it evidentially is not!
I also, after some reading, was lead to believe it was due to Internet Explorer’s ‘Compatibility Mode’, but after performing a few simple tests, this was quickly ruled out as the source of the problem.
At this point I was at a loss as to what to do, so since I am an MS Access MVP, I sent an e-mail out to my fellow Access MVPs to see what others might suggest. Alex Dybenko, provided me with the key piece of information to figure out the root cause of the problem. Using a nifty piece of software that he had, he was able to identify that the WebBrowser control (with my MS Access database) was returning that it was running as a User-Agent MSIE 7.0 on his system, even though his actual IE browser was MSIE10.0?! After performing the same test, I identified that my WebBrowser controls was reporting to be MSIE6.0 rather than MSIE10.0.
Hence, the WebBrowser control is actually running in a dumbed down mode, when compared to the actual version of Internet Explorer that you installed. So apparently, Google Maps does not play nice with older versions of Internet Explorer.
Knowing what the actual issue what, I when digging online to see what could be done. I eventually came across an obscure registry key that can be used to tell a program to use a specific IE emulation version.
The solution is a simple Reg Hack to for the WebBrowser control to switch it’s emulation to a more recent version of MSIE (MicroSoft Internet Explorer).
Open RegEdit and navigate to the following Registry Key (and yes you need to perform this registry hack on every computer running your database!) depending on the application using the WebBrowser control (not your OS!).
32-bit
HKLM\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

64-bit
HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

Then create a new DWord entry in which you specify the program executable that has the WebBrowser control in it as the ‘value name’ and use one of the following values for the Decimal ‘value data’
7000: IE7 Emulation
8000: IE8 Emulation
8888: Force IE8 Emulation
9000: IE9 Emulation
9999: Force IE9 Emulation
10000: IE10 Emulation
10001: Force IE10 Emulation
11000: IE11 Emulation
11001: Force IE11 Emulation
So since we are talking about an issue with the WebBrowser within our MS Access database, we create a DWord with msaccess.exe for the Value Name and I used 9999 as the value data. Error message gone.
As usual, you could easily create a bat, vbscript, VBA routine to push this into the registry as part of your program or installation routine! I was recently asked if I could supply an example of such code. As such, feel free to download one of my samples:
WebBrowserEmulationRegistryHack_MSAccess
WebBrowserEmulationRegistryHack_MSExcel
That said, be forewarned that improper editing of the Registry can permanently damage your computer to the point of it not working anymore. I assume no responsibility whatsoever for the sample/code provided. It is provided for educational purposes only, and it is your responsibility to validate and test it to ensure it works properly. It was put together rapidly in the hopes it might help, but has not been fully tested.
Also note, since it impacts the executable, in our case msaccess.exe, this hack will impact all databases containing WebBrowser controls. This could theoretically cause problems with older databases, so you could easily push the registry hack at the startup of your db and delete it upon closing, to try and minimize impacting other databases. Obviously, if they are opened at the same time, there is little you can do.
This hack works for MS Access databases, MS Excel, WPF, Visual Studio projects, anything that uses the WebBrowser ActiveX control.
Hopefully this will help someone else!
References
If you are looking for further information, fellow MVP Tom van Stiphout recently brought the following article to my attention: Web Browser Control – Specifying the IE Version
MSDN – Internet Feature Controls (see the section entitled Browser Emulation)
Extra
If you aren’t looking to fix the issue, but rather simply make the error not display, you can always place the following in the Form’s load event
Me.WebBrowserControlName.Object.Silent = True