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.
Related
Our servers are upgrading to Windows 10 64-bit (which is also using Office 64-bit products) and I noticed that in this environment, the old Outlook Redemption code I run in my MS Access VBA applications no longer work due to Access being unable to load the usual dll files (Redemption.dll, StrStorage.dll, dynapdf.dll). Is there a way to get this to work in 64-bit Office?
You will need x64 bit version of the app + dll's used. So if you using say tree-view, there not a x64 bit version. Same goes for any "add in", and that includes Redemption. You course of action is to find a x64 bit alternative, or hope that a x64 bit version of Redemption is released. Same goes for activeX calendar control, or any other add-in, or activeX control(s) you use. You have to ensure that x64 bit versions of such controls or add-ins are available before you can really adopt office x64 bit version.
Make sure the bitness of Access (where your code is running) matches the bitness of Outlook / MAPI system.
Since Redemption (unlike OOM) is an in-proc COM library, it bitness must match the bitness of your code (COM system takes care of that). But since Redemption loads the MAPI system in-proc, the bitness of the MAPI system must match the bitness of the host.
See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for more details.
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.
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.
Greetings for the day.
I am having a issue making my 64bit ActiveX component to run on Win8(64Bit) over IE10(64bit) browser.
ISSUE:
I am having a 64bit Intranet application in which I have an ActiveX component (COM .dll) which creates an explorer bar and a BHO in Internet Explorer.
I am trying to use this ActiveX Component in Win8 (64Bit) and IE10.
What works for me:
My 32 bit ActiveX version in Win8(64Bit\32bit)\Win7(64bit\32Bit) using IE10 without EPM enabled.
My 64bit ActiveX in Win7(64bit)\Win Server 2008 R2(64bit) using IE7\IE8 (64 bit).
My 64bit ActiveX in Win7(64bit) using IE10 having EPM enabled.
What does not works for me:
My 64bit ActiveX component in Win8(64bit) using IE10(64bit) having EPM enabled.
Having read all the blogs available over the internet, I learnt that for a 64bit ActiveX component to work in Win8(64bit) using IE10, I need to enable EPM(Enhanced Protected Mode) , register both 32bit and 64bit versions of my ActiveX and also my ActiveX should be EPM compatible. Also my dll should be located in AppContainer readable folder like Program Files.
Blog Links:
http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx
http://www.askyb.com/bho/step-by-step-guide-to-making-you-bho-epm-compatible-with-ie11-on-windows-8/
What I have tried So far:
Made my ActiveX component EPM compatible according to the above links.
(My ActiveX dll has 5-6 classes and different .rgs files for registering each. So I added the AppContainer GUID in a separate .h file and included that file in each class .cxx file. Also included the
‘Implemented Categories’ in all .rgs file.)
Registered both 32bit and 64bit versions of my ActiveX.
Enabled the EPM.
Now I am able to get only my explorer bar enabled with EPM. But other BHO functionality is not working.
One of the functionalities of my ActiveX is that it reads the Machine Name and returns it. But in Win8(64bit) using IE10 it is not working even after doing all of the above.
Bottom-line is that my ActiveX is not working completely as expected,ie., The instance of one of the BHO Component(which is used to read the clients Machine Name) is not getting instantiated as expected,same Component works fine with a 32 bit BHO Component on the same Environment :(
Is it something I did wrong in making my ActiveX component as EPM compatible?
As I want my application to run only in 64bit mode as it’s an intranet application, do I still need to register both 32bit and 64bit versions of my ActiveX?
Should both the 32bit and 64bit versions should be made EPM compatible?
Should both 32bit and 64bit have the same CLSID?
Any quick solution would be greatly appreciated, Since I’m going nuts working on this issue from past few days, hoping for a positive response from your guys.
Thanks in advance
My company has a VB6 application using Crystal Reports 7 which a client has asked to be installed on Windows 7 32 bit. It is currently installed on Windows XP 32bit SP2 machines at the client. Connection to the DB is done via ODBC to SQL Server 2000 instance on another server.
On Windows 7, the installation works fine, however when you try to open the application, the error is given.
I have looked at the following:
Registering all the dll's and ocx files using regsvr32. Some will not register as they either are registered already or the following message is given "Make sure that "[name].dll" is valid DLL or OCX file and then try again." I read this forum thread regarding this: http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/0653f685-4526-45d9-89f3-8c479a6b4c62
Monitored the opening of the application using a ProcessMonitor application to try and spot if there is a missing dll or ocx file - this does not seem to be the case.
Reviewed the application according to this list and nothing seems to be against these guidelines
I've noticed two items in the knowledge base that relate to this
http://support.microsoft.com/kb/281848 - the comdlg32.ocx bundled with the application is version 6.0.81.69 and the one in the system32 folder on the dev machine (WinXP 32 bit) is 6.1.97.82. However if this was the issue then surely it would not work currently?
http://support.microsoft.com/kb/184898 - I'm not sure how to confirm that this is the issue
Finally, due to complexities, I am not allowed to make code changes to this application. Even if I was, I'm not a VB6 programmer, just the guy who got the terribly support project! If code changes are required, then I'll have to investigate using WinXP mode.
Update: I get the same error in XP Mode. That's a Win XP with SP3 VM. This runs on a Win XP SP2 VM, is there potentially something in SP3 that would have caused this to occur? Or is it just a fact of it being XP Mode?
I got the same error but I solved by using regsvr32.exe in C:\Windows\SysWOW64.
Because we use x64 system. So if your machine is also x64, the ocx/dll must registered also with regsvr32 x64 version
The file msrdo20.dll is missing from the installation.
According to the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7 this file should be distributed with the application.
I'm not sure why it isn't, but my solution is to place the file somewhere on the machine, and register it using regsvr32 in the command line, eg:
regsvr32 c:\windows\system32\msrdo20.dll
In an ideal world you would package this up with the redistributable.
This download fixed my VB6 EXE and Access 2016 (using ACEDAO.DLL) run-time error 429. Took me 2 long days to get it resolved because there are so many causes of 429.
http://www.microsoft.com/en-ca/download/details.aspx?id=13255
QUOTE from link:
"This download will install a set of components that can be used to facilitate transfer of data between 2010 Microsoft Office System files and non-Microsoft Office applications"
You say it works once you install the VB6 IDE so the problem is likely to be that the components you are trying to use depend on the VB6 runtime being installed.
The VB6 runtime isn't installed on Windows by default.
Installing the IDE is one way to get the runtime. For non-developer machines, a "redistributable" installer package from Microsoft should be used instead.
Here is one VB6 runtime installer from Microsoft. I'm not sure if it will be the right version for your components:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7b9ba261-7a9c-43e7-9117-f673077ffb3c