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.
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
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'm having some compatibility issues with a legacy VB5 program I inherited.
Specifically, the DBCombo control.
Where does this control come from? I think it might be from the Microsoft DAO Object Library but I want to make sure.
It is, well, was, an ActiveX control last seen in VB6. The DLL that supported it was named "DBList32.ocx". If you have a really old machine on which it was installed then you could copy that file from the c:\windows\system32 directory and register it with regsvr32.exe.
I can still add it to the VS2008 .NET toolbox by right-clicking it and selecting Choose Items, COM tab and ticking "Microsoft DBCombo Control" (got VB6 installed on the machine). Didn't actually try to use it, odds are low after the Windows 7 SP1 update for ADO that broke backwards compatibility.
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.
I understand that I cannot load a 32 bit dll in a 64 bit process. I have a 32 bit dll (VB6 component), with no source code, that is loaded in an Excel automation macro. What are my options?
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.
There actually is a fourth option which is not mentioned in this article by Microsoft: You can create a 32-bit out-of-process COM server which serves as a proxy between your 64-bit macros and the legacy 32-bit COM components or create a COM+ application. A sample is provided here:
Accessing 32-bit DLLs from 64-bit code