Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Unblocking ActiveX controls in Vista / IE
Office / VBA General
It appears that Microsoft is changing the way the helper programs like ActiveX controls are handled. Numerous ActiveX's that worked under previous versions of Windows and IE are no longer bundled with the latest versions of IE (or Vista). If an upgrade is made to your IE installation you may have a problem on Win2000 or XP. If you bundle an ActiveX with your project, and it is on the Microsoft "Tested but not supported" list of ActiveX's and you are not a trusted source, then it will be blocked and your project can't use it. (Even though many of the ActiveX's were actually written by Microsoft.)
My interest was in using the Com Port with Excel to retrieve data from various lab devices and I used MSComm to do that. The add-in was installed on 5 laptops and worked fine. I installed the add-in on a new Vista computer and when I used it I received an error and looking through the project found that the MSComm control was not loaded and was unavailable even though my installer program had copied it into the System32 folder and had registered it. I could create an icon on the toolbar but when I went to copy it to a form I was informed that it wasn't trusted.
It turned out that Vista wasn't the issue. The ActiveX was being blocked by IE because I am not on the trusted source list. This is true of other ActiveX controls as well. I searched the registry for MSCOMM32.OCX and found the key. I searched for the key and found...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}]
"Compatibility Flags" = 00000400
The "400" value was blocking the ActiveX control. Setting the value of the compatibility flag to "0" cured the problem. Going back through the other laptops that I was using for data collection, I found that two of them running Windows XP had the same problem even though they had previously worked. My IT department had pushed out updates to IE.
The Tek-Tips community (and some other helpful sites) provided clues on how to fix the problem using VBA even if an update is pushed out to IE that once again blocks the ActiveX control. This works for my problem with the MSComm controls and should work for other ActiveX controls if you find them blocked.
Search the registry by the name of the activeX control and determine the million digit key name. Then search the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility" for the key name.
Before you change the value of the key, highlight the key and export it using the command from the Registry menu. This will create a backup just in case. Then right click on "Compatibility Flag" and select "Modify" and change the value to zero.
Here is the VBA that I put in the Auto-Open section of my code...
Everytime the Aut
pen code runs, it checks for the version of IE and converts the version code to a true number (6.0.2800.1126 becomes 6.028001126) and if it is over 5 then the key is checked. If there is a key then the variable TheKey will contain the value of the registry key (else it remains -1). If it is greater than 0 then the RegWrite line changes the key value to 0.
Now even if your IT department or "Windows Update" pushes out an update to IE, and IE once again blocks the ActiveX without telling anyone, opening the project unblocks it without fuss or warning dialogs.
I have editted this FAQ to remove the reference to using the shell command to open a .reg file to change the key value. RegWrite works without having to call anything else.
My thanks to StrongM here at Tek-Tips for the line on how to get the IE version. That lead to getting the key value of the Compatibility Flag. That lead to the solution.
My interest was in using the Com Port with Excel to retrieve data from various lab devices and I used MSComm to do that. The add-in was installed on 5 laptops and worked fine. I installed the add-in on a new Vista computer and when I used it I received an error and looking through the project found that the MSComm control was not loaded and was unavailable even though my installer program had copied it into the System32 folder and had registered it. I could create an icon on the toolbar but when I went to copy it to a form I was informed that it wasn't trusted.
It turned out that Vista wasn't the issue. The ActiveX was being blocked by IE because I am not on the trusted source list. This is true of other ActiveX controls as well. I searched the registry for MSCOMM32.OCX and found the key. I searched for the key and found...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}]
"Compatibility Flags" = 00000400
The "400" value was blocking the ActiveX control. Setting the value of the compatibility flag to "0" cured the problem. Going back through the other laptops that I was using for data collection, I found that two of them running Windows XP had the same problem even though they had previously worked. My IT department had pushed out updates to IE.
The Tek-Tips community (and some other helpful sites) provided clues on how to fix the problem using VBA even if an update is pushed out to IE that once again blocks the ActiveX control. This works for my problem with the MSComm controls and should work for other ActiveX controls if you find them blocked.
Search the registry by the name of the activeX control and determine the million digit key name. Then search the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility" for the key name.
Before you change the value of the key, highlight the key and export it using the command from the Registry menu. This will create a backup just in case. Then right click on "Compatibility Flag" and select "Modify" and change the value to zero.
Here is the VBA that I put in the Auto-Open section of my code...
Code:
Dim ieVersion
Dim RetVal
Dim TheKey As String
Dim winVersion
Dim NewStr, KeyFinder
TheKey = -1
Set KeyFinder = CreateObject("wscript.shell")
ieVersion = KeyFinder.RegRead _("HKLM\SOFTWARE\Microsoft\Internet Explorer\Version")
NewStr = InStr(1, ieVersion, ".", vbTextCompare)
ieVersion = Left(ieVersion, NewStr) & Replace(ieVersion, ".", "", NewStr, -1, vbTextCompare)
If Val(ieVersion) > 5 Then
TheKey = KeyFinder.RegRead("HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}\Compatibility Flags")
If TheKey > 0 Then
KeyFinder.RegWrite "HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{648A5600-2C6E-101B-82B6-000000000014}\Compatibility Flags", 0, "REG_SZ"
End If
End IfEverytime the Aut
pen code runs, it checks for the version of IE and converts the version code to a true number (6.0.2800.1126 becomes 6.028001126) and if it is over 5 then the key is checked. If there is a key then the variable TheKey will contain the value of the registry key (else it remains -1). If it is greater than 0 then the RegWrite line changes the key value to 0.Now even if your IT department or "Windows Update" pushes out an update to IE, and IE once again blocks the ActiveX without telling anyone, opening the project unblocks it without fuss or warning dialogs.
I have editted this FAQ to remove the reference to using the shell command to open a .reg file to change the key value. RegWrite works without having to call anything else.
My thanks to StrongM here at Tek-Tips for the line on how to get the IE version. That lead to getting the key value of the Compatibility Flag. That lead to the solution.