I have a 32bit VB6 Custom DLL which I was using all along until Excel 2013, Win-7. Now after moving to Excel 2016 on Win-10, the Excel file is rendered un-usable. I have done the Registration of that old DLL file on Win-10 via PowerShell (Admin mode) and it says registration successful. However, when the module in Excel executes creating the Object via CreateObject, it says ActiveX cannot create Object.
Another surprise that when I try to reference the VB6 DLL from (in Excel) Tools -> Reference, i can reference it and I can access the Class/Functions, but still when I try to execute it, it says the same error about ActiveX.
what else do I need to do in Windows-10 to have it run ?
32 bit programs can only load 32 bit dlls. 64 bit programs can only load 64 bit dlls. This is important. In COM which VB6 and Excel do, you can do non compatible bitness by forcing the wrong bitness dll into dllhost. All calls are marshalled with EXE servers. See https://learn.microsoft.com/en-us/windows/win32/com/registering-the-dll-server-for-surrogate-activation (note goggle sabotages searches for Windows).
Related
One of our users has an Excel VBA project that references Microsoft Windows Common Controls 6.0. The corresponding MSCOMCTL.OCX file is no longer in our image, and so of course the project won't run due to a missing reference.
Rather than installing Microsoft Visual Basic 6.0 Common Controls on our Windows 7 64-bit systems with Office 2016 64-bit, is there something different that the user can reference in their project that is more modern and supported?
Side question: If we do install it, will it even be able to work, with 64-bit Excel calling a 32-bit OCX?
Answer: I tried on a 64-bit Office installation, and the answer is No. You can install it, register it, and reference it, but you can't actually use any of the UI controls from it. They simply don't appear in the list.
My main stationary machine is a Windows box running Win 8.1 64-bit and Office 2013 32-bit. I developed a 32-bit DLL with functions in VS2013 which I include through Excel VBA. Functions work fine on Windows.
Then I have a Macbook Pro running Windows 8.1 64-bit and Office 2010 32-bit under Parallels 8. I do not seem to be able to work with the functions from my DLL under this Mac.
How I tried:
Copied my DLL file to a new folder C:\MyTools under Parallels.
Referenced this folder when loading the DLL in VBA. My VBA code to load a function from the DLL looks like this
Declare Function MyDLLfunction Lib "C:\MyTools\MyDLL.dll" (ByVal s As Double) As Double
I also tried double slashes \\ to no avail
The undesired result when using this function from my worksheet on Parallels is that there's an error code displayed in the cell (#VALUE).
Is it rather Excel 2010 not being compatible with DLLs in general (can't believe that), or is a matter of referencing the path with the DLL correctly on the Mac? I thought C:\MyTools\MyDLL.dll would work as this is how I see the file in the tree of Windows explorer in Parallels. Or is my Parallels 8 too outdated?
This is a shot in the dark, but it could be that your DLL is not compiled as a static library and hence there are certain dependencies which are present on your development computer (because of the Visual Studio installation) which are not there on the test computer/in the parallels environment.
Try running your DLL on Excel on an identical Windows system with no visual studio installed. If it doesn't work, the problem is likely to be as mentioned above.
I have two PCs, one has MS Office 2013 32bit installed and another MS Office 64bit installed.
I have Perl code that is using Win32::OLE Perl module to manipulate XLS spreadsheets.
The code is working perfectly fine on 32bit PC, but has a problem on 64bit one.
After doing some research here is what I found out.
The problem is the following line of code:
use Win32::OLE::Const 'Microsoft Excel .* Object Library';
I looked inside Win32::OLE::Const module and it seems that the module is looking for that library in the registry. When I printed out all entries from the registry from both 32 and 64 bit I found out that this library is available on 32bit and not available on 64bit.
Is there a way to install that library on 64 bit? If not, are there any other modules that would allow OLE automation of Excel?
All my Perl script needs to do is to open XLS file and save it as CSV. I am doing it with Spreadsheet::ParseExcel and Spreadsheet::XLSX in all other scripts. The problem with this particular XLS file is that it is password protected and using non-standard password encryption. So Spreadsheet::ParseExcel is not able to open it. Win32::OLE has no issues opening the file on 32bit.
Code can be provided if needed.
Please advise.
Thank you,
-Andrey
I use your Win32::OLE::Const module to have the Excel constants available in Perl.
Recently, I had a clean Win7 x64 install with Office 2016 and the script was not working anymore (using the latest version Win32::OLE::Const module which is installed with the current (on 06/04/2016) ActiverPerl 64 bit installation).
After some investigation, I have found out that the Win32::OLE::Const did not see the Excel automation object although it was well registered and available in the registration database.
In the registration database the following key contains the path to the Excel executable:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{00020813-0000-0000-C000-000000000046}\1.9\0\Win64
If I add manually a new key
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{00020813-0000-0000-C000-000000000046}\1.9\0\Win32
with the same path as for the Win64 key then the Perl script found the Excel typelib and worked again.
Hope this helps.
Registry key also helps with Outlook 2013.
/HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.5\0\win32
I developed a 64-bit Addin.
For testing I added it on a laptop (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010) [other than the one i developed the Addin on], its works fines i can call n use its functions. but when i add the same addin on a desktop machine (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010), its functions are not available and no error message displayed as well. But when i re-launch Microsoft Excel 2010 a message appears.
Message text : "The file you are trying to open, 'MyAddin.xll', is in a different format than specified by the file extension. Verify that the file is not corrupted and is in from a trusted source before opening the file. Do you want to open the file now?"
As per the message text i verified that the location for xll is included in "trusted location". Yet the issue not resolved.
Whats your opnion in this regard,
Thanks & Regards,
Maverick.
Check that you have compiled it Release and not Debug (if you've done the latter it will only work on machines with the debug versions of included DLLs, which usually means machines with Visual Studio installed).
Have an SSIS 2008 package that runs just fine on my local dev machine with Office 2007 installed. It has a script task with interop.excel as a reference. (I'm reformatting some excel sheets with it)
So everything works like a champ until I install and run it on my test SQL 2008 (Server 2008 64bit) server. I install to SSIS, execute it via a SQL Server Job, it runs though most of the steps but then throws an exception when it gets to the script task that needs the excel interop assembly.
I've installed the 2007 PIA and have execution marked as 32bit as well. At this point I'm just kind of lost. Any help is appreciated.
This script task - Is it a .NET script task or a 32-bit script task?
I'm guessing from the interop.excel reference, that its a .NET script task calling out to an old 32-bit library? Can you confirm?
If there is a 32-bit component that you are running on your Win64 environment then you need to be careful about what you are using to register it. By default, regsvr32 is the 64-bit version, so you need to use the regsvr32.exe under c:\windows\systemWOW64 (or something similar). This will ensure the dll is registered in the 32-bit hive of the registry, and available to the WOW (windows-on-windows) emulation environment.
SpreadsheetGear for .NET is an Excel compatible spreadsheet component for 32 bit and 64 bit .NET, and has an API which is similar to Excel's COM API.
You can see some live ASP.NET samples here and download the free trial here.
Disclaimer: I own SpreadsheetGear LLC
I installed Office 2007 on the server I was using. That fixed one problem. Then I discovered another problem that was alleviated by this SO Link