I'm using Windows 10 and Excel 2016 and I tried to install the Windows Common Controls (SP6) using the file mscomctl.ocx. It ran perfectly under Excel 2013 but not under Excel 2016. I'm looking for the ListView control which does no longer run on the new machine.
I performed the following steps:
Copy the mscomctl.ocx file from a running Windows 10 / Excel 2013 into the folder C:\Windows\SysWow64
Register the file with the cmd prompt regsvr32 C:\Windows\SysWow64\mscomctl.ocx
Referenced the mscomctl.ocx in VBA which then appeared in the list with a checked box
Checked the registry and theres only an entry for Version 2.2. Altough on the running machine I've got 2 entries: (Standard) & PrimaryInteropAssemblyName) where on the not running machine there's only the (Standard) entry.
Step No. 5 would have been adding the control to the Standard controls but None of the common controls does appear in the list.
Does anybody have experienced similar issues? If yes, could you resolve them?
Many thanks
Adrian
This is happening because mscomctl.ocx is a 32 bit only item. It will not work in 64 bit mode.
Addendum: in July 2017 Microsoft published a 64-bit version of mscomctl.ocx, thus since then it is possible to use its controls from Office 64-bit. The 64-bit version of mscomctl.ocx is also part of newer Office versions (like Office16). A good article about using mscomctl.ocx with Office 64-bit is available here.
Instead of coping the file from somewhere, you could always download them from Microsoft
Make sure the "Microsoft Windows Common Controls 6.0 (SP6)" reference does point on the SysWoW64 folder. If not Use the "Browse" button to select it.
Left click on the "Toolbox" -> "Additional Controls", make sure the "Selected Items Only" is not checked, and look for the "Microsoft ... 6.0 (SP6)" controls.
Note that you might experience issues when trying to open the resultant workbook in older versions of Windows and/or Excel.
Related
I've seen tons of posts and sites that address this issue. I've tried every solution I've found but none of them work (I've been trying to figure this out for days now). I have seen many posts with the same exact sounding issue, but either the solution didn't work for me or isn't applicable. With that said...
I have an add-in for Outlook 2007 that is intended to add text to the an email's title and body. It is installed for all users using an .msi file. There is an older version that I deployed last year that works fine. The new version I created has only a few minor input/output changes, nothing major. This new version works perfectly on my development computer in both debug from Visual Studio and from an actual install. However, I can't get it to work on a non-development computer. Here are the details on the program and target computer (development computer and target computer details are the same other than the fact that the target computer doesn't have Visual Studio):
-Using Visual Studio Professional 2013
-Written in Visual Basic
-Target Framework is .NET 4.0
-The add-in is only run once the "send" button on an email is clicked.
-Outlook version is Outlook 2007
-Operating system is Windows 7 Enterprise SP1 32-bit
The problem is that the add-in won't load on the target computer(yes, I know, a bazillion other people have had the same issue). As I said previously, it works fine on my computer in both debug and installed versions. This made me think that the other computer is missing something, so I tried installing the .NET 4.0 framework onto the target computer but it told me that it was already installed. I ran through everything I could think of to get it to work with no avail. Here's how it behaves:
-Installs fine with no errors.
-HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/Outlook/Addins/EmailMarkTool/LoadBehavior = 3 after installation.
-VSTO_LOGALERTS = 1
-VSTO_SUPPRESSDISPLAYALERTS = 0
-Outlook opens with no apparent errors.
-LoadBehavior = 0 immediately after Outlook is opened.
-Shows up in the Add-ins under "Inactive Application Add-ins."
-Never shows up under "Disabled Add-ins."
-In the "COM Add-Ins" dialog where I can check which add-ins to use, it shows the correct directory and the Load Behavior is "Unloaded."
-The add-in can be checked. When I click "OK" I don't get any errors. When I go back to the Add-ins, it is unchecked and "Unloaded" again.
-Setting the LoadBehavior to 3 doesn't help because it goes back to 0 as soon as Outlook is started again.
-I inserted a try-catch block into the New() function of the add-in that has a MsgBox pop-up and a Throw.
-I get absolutely no errors anywhere.
-No log file is generated.
I have tried uninstalling, rebuilding, and reinstalling multiple times all with the same result. I just can't figure out why it will work on my development computer but not the target computer. Thanks for reading all of this. I know it's a lot, but I needed to get the details out. Thanks in advance for any input!
[UPDATE]: I just created a brand new minimal add-in just to test if it would work but got the same results.
I found the problem!
The problem may be unique to Outlook 2007. It turns out Microsoft Office 2007 SP1 and SP2 had a bug that prevented it from running VSTO addins. Microsoft released a hotfix that fixes this issue (https://support.microsoft.com/en-us/kb/976477). This was added in to the release of Microsoft Office SP3. However, to activate the fix, a new registry flag must be created but that isn't automatically done with the fix, making the fix useless until you manually activate it (instructions and download here). So...
To enable VSTO addins in Outlook 2007, you have to add a subkey to this registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Common\General\
and add a DWORD "EnableLocalMachineVSTO" with the value set to 1.
I did this, restarted the computer for good measure, installed my addin for the 23rd time, and it installed and ran perfectly! I'm not sure how previous versions worked, though. It's possible that our system admins removed that subkey in an effort to bolster security at some point.
The loadbehaviour key problem you are experiencing is strange. Whilst I think this is probably not your solution, it could be, so its worth a try.
The target computer will need to have VSTO tools for office runtime installed.
You can download these tools are the following link - https://www.microsoft.com/en-GB/download/details.aspx?id=48217
Solution
I have added a Treeview Active X Control to one of our spreadsheet, using Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e. MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition) (MS16-004), pushed out from Microsoft on 2016-01-15 (or thereabouts), installs a new version of MSCOMCTL.OCX (v6.1.98.46) which was "Created" on 2015-12-09, but "Accessed" (i.e. installed on the computer) at the time of the update.
This made the workbook "lose" reference to MSCOMCTL.OCX (quote marks on "lose", because the reference is still ticked but no longer works; the workbook doesn't compile because of "Compile error: Object library feature not supported" or "Automation error").
It seems that the update modifies the following registry key by adding a SubKey 2.0, but leaves it empty, and doesn't register the new MSCOMCTL.OCX:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\
Fixing the problem requires three steps:
MSCOMCTL.OCX needs to be unregistered and re-registered from an elevated command prompt, as follows:
C:\Windows\system32>Regsvr32 /u C:\\Windows\SysWOW64\MSCOMCTL.OCX
C:\Windows\system32>Regsvr32 C:\\Windows\SysWOW64\MSCOMCTL.OCX
When registering the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32, a new key is added to the Registry:
KEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
If there was a SubKey named 2.1 already existing, it enters a reference that 2.2 is now the Key for use. But it doesn't do anything to the empty 2.0 SubKey !
If there is a 2.0 (or 2.1 for that matter) SubKey with nothing in it, any object using that OCX should fail to create because it will use the 2.0 (resp 2.1) Version, it can't and didn't check for 2.2 Version.
Clean up the registry by deleting the wrong or superseded keys 2.0 and 2.1, leaving only the latest and working key 2.2. This can be done from the Registry Editor by selecting HKEY_CLASSES_ROOT, Edit/Find/MSCOMCTRL.OCX.
(Note: this step seems optional as I have checked that doing only step 1 and 3 made the workbook work again. But it feels like the right thing to do)
In the in the Excel workbook VBA project, Microsoft Windows Common Controls 6.0 (Service Pack 6) needs to be unreferenced and re-referenced. Re-referencing is not just a matter of re-ticking the box, you need to use "Browse", and select MSCOMCTL.OCX in C:\Windows\SysWOW64\
(Note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
Daniel Alexander Karr (refer post further below) has kindly shared a script he wrote to do steps 1 and 2 automatically (note that needs to be run as an Administrator).
Thanks Daniel and wmelonman for your help in understanding the problem and finding a solution.
Original Post
Similarly to what is described in this 3 year old post
(VBA Automation Errors due to Office Service Pack 3.0 caused by Forms), a perfectly working workbook of mine stopped working from one day to the next...
In the list of updates carried out last night the following ones are Office Updates:
KB3114563 (Definition Update for Microsoft Office 2010 32-Bit Edition)
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114555 (Update for Microsoft Office 2010 32-Bit Edition)
KB3114553 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114564 (Security Update for Microsoft Excel 2010 32-Bit Edition)
There were other updates, but general Microsoft Windows updates, not specific to Office, and they hopefully are not relevant here.
My understanding is that the "Automation error" is due to the project not compiling because of the presence of 2 "additional" ActiveX controls on one of my forms that I have referenced from Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e., MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
Unfortunately un-registering and re-registering MSCOMCTL.OCX as explained in the aforementioned post didn't solve the problem.
I also tried deleting all *.exd, but there weren't any on my C: drive.
Additional info that may be relevant:
The MSCOMCTL.OCX file version is 6.1.98.46, created & last modified 2015-12-09 but accessed at 3.33am yesterday (2016-01-15), i.e. about the same time the updates occurred (3:14am for the latest one).
Once passed the initial "automation error" message, I would get an additional message, "Compile error: Object library feature not supported", highlighting lines of codes associated with the additional controls.
I've verified these were "causing" the problem by creating a blank form an trying to add one on. I got the error message "Could not complete the operation due to error 800a0011".
These additional controls are Microsoft TreeView Control 6.0 (SP6) and Microsoft ImageList Control 6 (SP6).
I could add the Microsoft TreeView Control, Version 5.0 (SP2) and Microsoft ImageList Control, Version 5.0 (SP2) without raising the error (I didn't try making them work though).
Does anyone know of similar mishap with MSCOMCTL.OCX following yesterday's Microsoft updates? That may confirm it could be the source of my problem.
Does anyone know of a fix?
Does anyone know how to report this to Microsoft (if indeed it is the source of the problem)?
And finally, for those interested, there is a way to avoid Microsoft Updates messing up ActiveX controls...not using them! This is what JPK has done for his TreeView.
our Business-ERP-Software Faktura-XP got the same problem since yesterday, we investigated the Problem and created a Patch for it, maybe it will help someone:
http://www.faktura-xp.de/faktura-xp-download/update-und-patch-oeffentlich.html#toggle-id-4
In our Case, the TreeViewControl stopped working, but it will be the same Problem with Automatition. Microsoft updated the MSCOMCTL.OCX to Version 2.2, if the Key
{831FDD16-0C5C-11D2-A9FC-000F8754DA1} has an empty 2.1 or 2.0 Entry the Common Control will stop working.
Solution:
Delete Key 2.0 and 2.1, leave 2.2, unregister the mscomctl.ocx and reregister it.
Our Patch will do exactly this, nothing more, nothing less, but as simple as possible for our customers, just click Next and Close.
Edited for more information:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
is freshly created when register the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32
When there is a SubKey named 2.1 it enters a reference that 2.2 is now the Key for use.
If there is a 2.1 SubKey with nothing in it, your Object will fail to create because it will use the 2.1 Version, can't and didn't check for 2.2 Version.
Delete this Key if neccessary and youre good to go.
Further Testings shows that 2.0 SubKey is obsolete and could cause Problems.
Mostly Systems with Microsoft Windows 7 had this Problem. For our Software, no-one with Windows 8.1 or Windows 10 called a Problem after the current Update.
Similiar problem here: Ancient Access 97 app on ancient XP (not for long anymore, sigh of relief) quits saying "Error 91: Object variable or With block variable not set". Examination showed it happens when the progress bar control which resides in Mscomctl.ocx is adressed.
I found that KB2881029 (MS16-004) is the culprit. It installs the new version of MSCOMCTL.OCX. On machines w/o this update the Access app works fine. But it is not suited for removal, at least this is what our WSUS told me when I was going for it. Anyway we wouldn't want to live w/o a security update.
Having read the answer concerning HKCR\TypeLib{831FDD16... I tried deleting the at that time still populated \2.0 subkey prior to installing the update only to find out that even with a non existing \2.0 subkey the update does create the empty one on installation. Well done, Microsoft...!
Thanks all for your contributions,
I have found that de-referencing and re-referencing the Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project would finally make it work.
!!!...BUT...!!!
Simply un-ticking / re-ticking the tick box would be too simple ! For re-referencing it, you need to use "browse", and select MSCOMCTL.OCX in c:\Windows\SysWOW64\
(note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
I have tried simply doing this on a machine where I hadn't run Daniel Alexander's Patch (to un-register and re-register MSCOMCTL.OCX, and remove the old empty 2.0 key from the register), and it didn't work, so I expect the above steps are required. I will try to thoroughly test which steps are necessary and edit this answer to spell out the whole procedure, step by step, but for the time being running Daniel Alexander's patch (AS ADMINISTRATOR !) and re-referencing Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project seem to work.
The problem has been described in detail here:
"Error messages or Access crashes after you install security update MS16-004"
MS: Article ID: 3139567
(Last Review: 02/16/2016 19:15:00 - Revision: 3.0)
https://support.microsoft.com/en-us/kb/3139567
I need the ListView control for a VBA project. To use it, I referenced Microsoft Windows Common Controls 6.0 (SP6) and drew a GUI in Office 2010 on Windows 7 (64-bit) containing the ListView object. When I opened the VBA project at work (Office 2007 on Windows XP), an error message said "Can't load the object because it's not available on this machine". When I opened the References dialog, I saw this:
There are two "Microsoft Windows Common Controls 6.0 (SP6)" items: one "MISSING" and one available (but unchecked). The file paths are different: the missing one is supposed to be located in C:\Windows\SysWOW64\MSCOMCTL.OCX, while the available one is located in C:\Windows\system32\MSCOMCTL.OCX.
Why isn't Excel/VBA able to use the available reference? Are these libraries different, despite having the same name? Is one a 64-bit version and the other one a 32-bit one (both Office versions are 32-bit if I recall correctly). How to make my VBA project inter-operable across different Windows or Office versions?
If both versions of Office are 32-bit, I would hazard a guess that the CPU/OS on your home machine is 64-bit, but your work machine is 32-bit. When you have a 32-bit CPU and OS, the drivers are all 32-bit and located in the System32 folder. On a 64-bit CPU/OS, the 64-bit drivers are located in the System32 folder (confusing I know) and the 32-bit ones are located in the SysWOW64 folder.
If you set the path to "C:\Windows\system32\MSCOMCTL.OCX", it should work on both machines because windows will automatically redirect your app to use the SysWOW64 path if necessary, with a few caveats listed on the linked page.
I am writing an application in VB.NET that will send emails using outlook. My problem is that I need the Office 2010 PIA to do this. The following are the steps I have already tried (I am using Visual Studio Express 2012):
Restarted the machine
Downloaded Office 2010 PIARedist and installed it
Restarted Visual Studio
Restarted the machine again
Uninstalled Office and the PIA and re-installed Office, making sure that the PIA was selected in the installation options (it was already selected by default, so presumably I installed it the first time I installed Office as well).
Restarted the machine again
Downloaded Office 2010 PIARedist and installed it again
Restarted VS
After each of these steps, the PIA is still not available in "Add Reference" in VS, nor do the files exist on my computer at all (a search for "Microsoft.Office.Interop.Outlook.dll" confirms this). I am running Windows 7 on my MacBook Pro. Does anyone know what my problem is here? This seems like a ridiculous amount of headache for such a simple feature.
PS The only reason I need the PIA is to be able to add CC recipients on the email. That's it. If anyone knows how to do that without the PIA, please let me know because I'd much rather just do that and be done with it.
PSS Both times when I installed the PIA itself, the installation ended silently (no indication of success or failure).
In case anyone stumbles on this question, I finally figured out how to add the interop. For some reason, it won't show up in the "Add References" window (maybe it's because I have VS2012 (11.0) and I'm using Office 2010...?) Anyway, I had to manually browse to it to add it. It was located in C:\Windows\assembly (all of the Office 2010 interops were in there). Also interesting was that a search of the entire C drive for 'Microsoft.Office.Interop.Outlook' or shortened versions of that string turned up absolutely no results, even though they are on the drive. One last note: although 'Microsoft Office 14.0 Object Library' shows up in the "Add References" window, adding that reference did not allow access to the interop.
Access 2010-application using TreeView (MSComctlLib.TreeCtrl.2) shows and populates as expected but suddenly after windows security patches doesn't fire events back to VBA.
Tried with rolling back MSCOMCTL.OCX in /syswow64, but no luck.
Please ping any similar behaviour or hints for fixing the issue.
regards,
The problem appears to be that the registry entries for mscomctl.ocx are broken after the security update. One solution can be found in this KB article. It suggests to run this batch file as administrator:
reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
if exist %systemroot%\SysWOW64\cscript.exe goto 64
%systemroot%\system32\regsvr32 /u mscomctl.ocx
%systemroot%\system32\regsvr32 mscomctl.ocx
exit
:64
%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx
%systemroot%\sysWOW64\regsvr32 mscomctl.ocx
exit
I've verified that this works in our environment.
I opened an Access file developed on 32-bit Access 2013 running on Windows 7 32-bit, and had experienced this problem when opening it on 64-bit Access 2013 running on Windows 8 64-bit.
My solution:
Delete the control and add it back again, using the design view on your Access form.
Because the treeview's properties are mostly set programmatically, there should be little to do aside from repositioning it and renaming it.