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.
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 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.
we have a mixed environment. Some workstations have Microsoft Office 2010 installed while others have Microsoft Office 2007 installed. A lot of our in-house developed applications are referring to the Outlook 12.0 object library and the Excel 12.0 object library. In Office 2010 these are referring to the 14.0 object libraries. Is there a way when users launch an Access application that it checks which version of Office they have installed and when it detects either Office 2007 or Office 2010 so that it can programatically set the correct references to the Object Libraries?? Many thanks for any help and/or suggestions.
Set the references to use the earliest version of the reference and Ms Access will automatically upgrade the reference for later versions of Access if needed.
For example, if none of your workstations use anything less than Access 2007, you should set the reference to Excel 12.0. Any workstation using Access 2010 or 2013 will update the reference automatically for their local copy
I've had similar conflict issues between office 2010,2013 and 2016.
I think the whole point of initiating this thread is that "should" <> "does"...
Meaning that programing to the earlier version does not "always" work when the user PC is not running the exact same version of MS Office that was used during development.
I think maybe need to somehow add both object references to the compiled version and then the app can pick.
In other words, I think the development PC needs to be running both versions of Outlook.
You could also alternatively develop the app on a PC running the earlier version and then save off a copy to be compiled in a newer version of office on a different PC. You'd be basically generating versions specifically for each version of Office.
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 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