I have a VBA project which runs perfectly upto windows 7 (both 32,64 bit) and upto office 2010. But when i try to run it on office 2013 or 2016. It does not load treeview control and gives error at:
Private SelectedNode As MSComctlLib.node
The things i have already tried are:
Followed this post thoroughly
http://thesmileycoder.com/treeview-working-in-access2013/
Re-registered MSCOMCTL.OCX/MSCOMCT2.OCX several times on both SYSTEM32 and SYSWOW64 folders.
Any help is appriciated!
Thanks for clarifying that you're using Office 64-bit.
You should see this article
Specifically the section:
Most things included in the 32-bit version of Office are included in the 64-bit version of Office.
The following are some things not in the 64-bit version of Office.
ActiveX controls library, ComCtl - This library contains ActiveX controls used to build solutions. It is most commonly used in Microsoft Access, Microsoft Excel, and Microsoft Word.
SharePoint List control The list view in SharePoint Technology isn’t available in 64-bit version of Office.
Followed by:
ActiveX controls library, ComCtl - Any solutions using these controls don’t work. No good alternatives are available for some of these controls.
EDIT
And this page for 2010 spells it out in more detail:
Native 64-bit processes in Office 2010 cannot load 32-bit binaries. This includes the common controls of MSComCtl (TabStrip, Toolbar, StatusBar, ProgressBar, TreeView, ListViews, ImageList, Slider, ImageComboBox) and the controls of MSComCt2 (Animation, UpDown, MonthView, DateTimePicker, FlatScrollBar).These controls were installed by previous versions of Microsoft Office and are installed by 32-bit Office 2010. An alternative must be found for existing Microsoft Office VBA solutions that utilize these controls when the code is migrated to 64-bit Office 2010. 64-bit Office 2010 does not provide 64-bit versions of the Common Controls.
Related
I am looking for the way to implement MS Word plug-in for Mac and Windows. The plug-in should work with all versions of Microsoft Office (Microsoft Office 2003, Microsoft Office 2007, Microsoft Office 2010, Microsoft Office 2013, Microsoft Office 2016) and should work on Windows XP - Windows 10. It should work on MS Word on Mac also (at least on the latest versions).
It seems to be impossible to create one app for all of this OS and versions.
Description of the plug-in: The plug-in should help user to find the definition of any word (the definition will be in the beginning of this file or in the other file on the user's local disk). For example, user place mouse over word "math", a plug-in shows pop-up with definition "Mathematics (from Greek μάθημα máthēma, “knowledge, study, learning”) is the study of topics such as quantity (numbers), structure, space and change".
I am thinking about some variants of implementation.
First variant. I can make plug-in with help of WinForms and Microsoft.Office.Interopt for all Windows OS and versions of MS Office. I can create add-ins for Word on Mac with help of JavaScript. (Add-ins on JavaScript don't work on Microsoft Office versions < 2013).
Second variant. I can create plug-in with help of VBA for both platform and for all versions.
Are these variants possible? What the best way to create plug-in for Windows and Mac?
First variant. I can make plug-in with help of WinForms and Microsoft.Office ...
This, sound to me, way you should go if you would like to support older Office products (2010 and older). You would create VBA or COM/VSTO version for older versions on Windows. For older versions of Mac (ex:Entourage) you should consider AppleScript scripting extendability. Office Add-in (JS API) for newer versions on Windows and Mac together.
Second variant. I can create plug-in with help of VBA for both platform and for all versions.
No such thing as VBA add-on for Mac. You may efficiently use AppleScript for scripting certain actions in older Office for Mac.
This is all about your requirements. At the end you will make your decision. I would go with Office JS API as the start and later on see if you have strong demand of your app for older versions of Office.
Yes it is possible, but refine your requirement.
Go for Apps for Office (Windows + Mac) and not Com Add-ins (Only in Windows).
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.
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.
Does anyone know if there is a way to make an Excel 2003 Document Level Customization work with Excel 2010? When I try to execute this document level customization built on Excel 2003 and VSTO 2005 SE, I get the following error.
"The assembly * could not be found at or could not be loaded.
You can still edit and save the document. Contact your administrator or the author of this document for further assistance."
Any help would be appriciated.
Just to share with people what I've learned thus far.
Office 2010, specifically in this case Excel 2010, has 64bit compatibility issues with Document Level customizations and I think Add-Ins when executing solutions built on Excel 2003 files. This appears to be an issue more specifically with Visual Studio Tools For Office SE (VSTO) where the OTKLoader.dll, being 32 bit, can't be loaded by Excel 2010 64bit version.
Our specific test was to take an Excel 2003 Document Level customization built by Visual Studio 2008, and install it on a Windows 7 64 bit machine running Office 2010 64 bit. The error received is the error as stated in my original question.
We then took a Windows 7 64 bit machine running Office 2010 32 bit and installed the Office Business Application. The OBA, the documen level customization, executed without error.
You'll probably want to reference the following article from Microsoft.
"Compatibility Between the 32-bit and 64-bit Versions of Office 2010"
http://msdn.microsoft.com/en-us/library/ee691831.aspx
I personally haven't made it through the article completely, but there's enough descriptive text and some explict statements that lead me to believe that Office 2003 customizations, currently, are not compatible with Office 2010's 64 bit version.
Hope that helps someone out there. This was a real pain to sort out.
Note the options we're presenting at this time are to:
A: Only allow 32 bit versions of Office 2010.
B: All Office / Excel 2003 Document Level Customizations must be upgraded, at a minimum, to Excel 2007 solutions.
No you cant, because interop/vsto library you reference has to be different.
Excel 2003 works on VSTO 2005 SE whereas Excel 2010 needs VSTO 2010 library.
VSTO 2005 doesnt work with Excel 2010 and VSTO 2010 doesnot works Excel 2003.
To expand on your findings, Rob, yes, that is correct (you can). I believe the other contributor has made a mistake.
For 32-bit versions of Office, it will work (and it does, so you have found), but it will not work for 64-bit editions of Office. Microsoft clearly states this compatibility restriction (well, as a footnote at least).
See the MSDN article Running Solutions in Different Versions of Microsoft Office.
Under section "Running Office Solutions Created By Using Previous Versions of Visual Studio", you will see in the chart in the last row that using VSTO 2005 SE with a project template targeted for Office 2003 will run on Microsoft Office 2003, Microsoft Office 2007, and Microsoft Office 2010 (32-bit only).
It goes on further to say that you will be required to install the Visual Studio 2005 Tools for Office Second Edition runtime on the client's PC.
Your options that you described are correct. Those should be the only options that you have.
I am struggling to apply an existing 32bit COM addin to 64bit Microsoft Word 2010.
To make the addin visible to Word, I have used the dllsurrogate-method, as it described here.
The problem is that now addin caused some strange exception when tries to add its toolbar and menu to office's. I cannot figure out, what it is, it seems, that the command bar reference became not valid in unpredicable moments.
Can anyone explain this?
Note, that everething is fine when I use the same addin under 32bit Microsoft Word 2010 and more old versions of Ms Office.
32-bit add-ins are not supported on 64-bit. Microsoft recommends to use the 32-bit version of Office unless you run into the memory limitations of a 32-bit process which is only likely to happen if you need to deal with extremely large spreadsheets:
The recommendations for which edition of Office 2010 to install are as follows:
If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.
If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.
If you need to go with the 64-bit version because of the memory limitations you have the following options:
If you have the source code, you can generate a 64-bit version yourself,
You can contact the vendor for an updated version,
You can search for an alternative solution.