3

I have an Excel add-in on a VM that uses the "Microsoft TreeView Control, version 6.0" as a part of Microsoft Windows Common Controls 6.0 (SP6), located at C:\Windows\system32\MSCOMCTL.ocx. The properties window on forms that use the TreeView control show the control as [TreeView control name] TreeView3. Everything works great, and I don't receive any errors.

I also have copies of the working VM with the same Excel add-in, but I receive a Microsoft Forms error that reads "Could not load an object because it is not available on this machine." when I open Excel and the add-in loads.

I am able to re-create the forms, using the same "Microsoft TreeView Control, version 6.0" (same file location and reference), but this TreeView control appears as [TreeView control name] TreeView2 and the error no longer appears.

Instead of re-creating all the forms that use the TreeView2 control, how can I prevent the issue from happening in the first place? The machines are obviously not exact copies. With the exception of .NET v4 installed on the working machine, I don't know what has changed that corrected the issue. It is my understanding that the Windows Common Controls should not be impacted by simply installing .NET v4 on the machines that have the error.

EDIT:
Installed the following and it did not work:
https://www.microsoft.com/en-us/download/details.aspx?id=10019

Also took a shot and installed .NET v4, and still no luck.

Specifications on working machine:
Windows 7 Professional SP1
Excel 2010, Version: 14.0.7162.5000 (32-bit)
Computer\HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP and it has v2.0.50727, v3.0, v3.5, and v4

Specifications on machines with the issue:
Windows 7 Professional SP1
Excel 2010, Version: 14.0.7162.5000 (32-bit)
Computer\HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP and it has v2.0.50727, v3.0, v3.5

EDIT #2: failed to mention that the machine with the issue is a 64-bit OS

Information from Registry for versions of TreeView controls on Working machine and Non-Working machine

Working Machine
Computer\HKEY_CLASSES_ROOT\MSComctlLib.TreeCtrl\CurVer - MSComctlLib.TreeCtrl.2

Computer\HKEY_CLASSES_ROOT\CLSID{C74190B6-8589-11D1-B16A-00C0F0283628}\Version - 2.1

Windows 7 Professional SP1 32-bit

Non-Working Machine
Computer\HKEY_CLASSES_ROOT\MSComctlLib.TreeCtrl\CurVer - MSComctlLib.TreeCtrl.2

Computer\HKEY_CLASSES_ROOT\Wow6432Node\CLSID{C74190B6-8589-11D1-B16A-00C0F0283628}\Version - 2.0

Windows 7 Professional SP1 64-bit

Community
  • 1
  • 1
Tom
  • 461
  • 1
  • 3
  • 12
  • Are you seeing _TreeView control name] TreeView3_ in the VB6 IDE? Is it possible there are multiple copies of the mscomctl.ocx on the machine with the issue? – jakdep Dec 09 '15 at 03:13
  • This is actually VB7 IDE. I couldn't find a tag for vb7. But, yes there are two copies that could be the same. "Microsoft Comm Control 6.0 (SP6)" in C:\Windows\system32\MSComm32.Ocx, and "Microsoft Windows Common Controls 6.0 (SP6)" in C:\Windows\system32\MSCOMCTL.OCX. I thought updating to the newest version of the controls would get me out of "hell", but that didn't work. – Tom Dec 09 '15 at 18:53
  • The MSComm32.ocx is unrelated to the this issue. I believe the _Comm_ is short for communication, not common. – jakdep Dec 09 '15 at 21:28
  • By VB7, I assume you mean Visual Studio.NET? Is that correct? VB6 was more of a dedicated IDE, where as later versions of Visual Studio allowed you to code in different languages (VB.Net, C#, etc.) – jakdep Dec 09 '15 at 21:30
  • I think my terminology is wrong. In Excel 2010, I use Alt+F11 to open Visual Basic for Applications. From the Help menu > About Visual Basic for Applications > the version reads "Visual Basic for Applications 7.0". I tagged the question as .net and vb.net because I wasn't sure if it is related to the framework on the machine. – Tom Dec 09 '15 at 22:51
  • OK, now we are on the same page. :) I doubt that the .Net framework has anything to do with it as it uses its own controls and installing it on the problem machine did not help. – jakdep Dec 11 '15 at 05:26
  • On the two machines I tested it on, the TreeView control type was showing as _TreeView3_. Can you verify that the versions of the MSCOMCTL.OCX file is the same across both machines and the there is only one copy of the .OCX on the problem machine? – jakdep Dec 11 '15 at 05:30
  • Updated question with details from the registries on both machines. Also, the machine with the issue is a Windows 7 64-bit machine. – Tom Jan 05 '16 at 20:34
  • Taking the MSCOMCTL.ocx file from the working machine, unregistering the MSCOMCTL.ocx file on the machine with the issue via regsvr32 and registering the ocx from the working machine seems to have done the trick. I am not including this as an answer since I still don't know how to prevent it. – Tom Jan 07 '16 at 16:42
  • Glad you managed to get it working. Was the versions of the MSCOMCTL.ocx files the same on both machines when it was still not working? – jakdep Jan 07 '16 at 23:43
  • No, the versions were not the same on both machines. Once I registered the MSCOMCTL.ocx from the working machine, the version in the CSLID registry key noted above changed to 2.1. – Tom Jan 13 '16 at 03:04
  • It might be that an older version of the file was replace with the current one, but it was not registered at the time. – jakdep Jan 13 '16 at 22:40
  • 1
    It appears to be related to the following articles: https://support.microsoft.com/en-us/kb/2597986 and https://technet.microsoft.com/library/security/ms12-060 and https://www.microsoft.com/en-us/download/details.aspx?id=30622 (the actual update). Had the same problem again, used the installer from the last link and it fixed the problem, although it didn't update the Version from 2.0 to 2.1. – Tom Jan 29 '16 at 16:15
  • It looks like the TreeView control has been updated again and causes problems after more Msft updates - http://stackoverflow.com/questions/34803843/excel-vba-automation-error-due-to-jan-2016-office-update-probably-caused-by-m – Tom Jun 30 '16 at 20:25
  • Had this problem back in 2010 when my employer upgraded from Excel 2003 to 2010. Reregistering the mscomctl.ocx fixed the problem for me as per @Tom's comment. – Rik Sportel Jul 07 '17 at 13:35

0 Answers0