I have a Visual c++ application that uses imports on the office COM components to manipulate office documents.The app relies on the installed office version on the users' machine.The example below is a section of a type library header that I have generated for excel from my installed office version(2010):
// Created by Microsoft (R) C/C++ Compiler Version 10.00.40219.01 (e8ba858a).
//
// d:\play_ground\pimawordtopdf\release\excel.tlh
//
// C++ source equivalent of Win32 type library C:\\Program Files (x86)\\Microsoft Office\\Office14\\EXCEL.EXE
// compiler-generated file created 11/26/14 at 09:02:55 - DO NOT EDIT!
//
// Cross-referenced type libraries:
//
//
#pragma once
This is working great on my other test machine with office 2007 installed but some things fail to work properly on a machine with office 2013 . My question is: are type libraries for microsoft office backward compatible so that those generated with 2010 work for 2007 .If this is true I would have to generate 2013 type libraries and compile my app with them so it works on 2013 ,2010 and 2007 .
Thank you for your time.
Yes, type libraries are backward compatible until you use only types available in all Office versions, not new members from the latest versions. You will get an exception if you try to call a member which is missed in the old Office version. That's why I'd suggest using the oldest type library, for example, for Office 2007 if it is the min supported version. If required, at runtime you can check the Office version, and if the code is run against the newest version, you may call new members.
but some things fail to work properly on a machine with office 2013
Could you please be more specific? Did you try to debug the code? Do you get any exceptions?
Finally, you may find the Office Automation Using Visual C++ article helpful.
They should, but they don't. It's Microsoft we're talk about, so they can do whatever the heck they want.
They did break that COM interface and it's no longer backward compatible.
For example, if you're using Shapes.AddMediaObject, then you're in trouble because it's deprecated Shapes.AddMediaObject2.
reference: https://msdn.microsoft.com/en-us/library/office/ff744080.aspx
Related
I ran Dependency Walker on an assembly (.exe) after compiling in Debug (Any CPU) and it seems like there are older core and kernel issues. The entire code is VB.NET 2010, so I am wondering why VS2017 Pro didn't clean those out?
Something interesting was that the Conversion to a new VS version did not occur, for which errors are shown -- it just showed the forms, modules, etc. as if there were no errors.
Should I try a Reload or something?
The errors were caused by having old references or assembly libraries which called DLLs (like VBIDE.dll and MSCORE.DLL) in the applications folder. There were very old references, some of which were to VB6.
Recall, remember that Visual Studio has always been dropping certain Windows forms controls over VB 2005, VB 2008, VB2010, etc. so you need to make sure those older controls are not in forms when you upgrade to e.g. VS 2017.
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 an created an add-in for Word which communicates with a third party cmd-program via an api I have written in c# using visual studio. The communication takes place using stdin and stdout.
The program works for word 2007, 2010, 2013, 2016 for Windows.
I have also successfully ported it to Word 2011 for Mac. The api here is written in c using xcode, but still using stdin and stdout. The api on mac is a dylib, which I can reference in the visual basic editor.
I'm having trouble replicating this on the 2016 version of Office for Mac.
I'm suspecting it might not be possible, due to new security restrictions.
When I try to reference a file I can only choose .tlb files (type libraries). I have only created tlb files using visual studio on Windows and have no idea how you might do that on a mac.
Can anyone answer if what I'm trying to do is even possible on the 2016 version of Office for Mac, and where I might find documentation on how to create files that can be referenced?
FYI: The add-in is called WordMat: www.eduap.com
Additional info following information from #erik below
I'm having trouble declaring the functions in my lib. Here is my declare statement:
Declare PtrSafe Function VBstrlen Lib "/Library/Application Support/Microsoft/Office365/User Content.localized/Add-Ins.localized/libMaximaConnection.dylib" (ByVal s As String) As LongPtr
The function is a simple test function which returns the length of a string. The declare function works as expected in Word 2011 using the above path.
The error reported is error 53 file cannot be located
The dylib is 32-bit compiled, hence I would not expect it to work since the 64-bit upgrade of Office 2016, but I would expect an error 453 DLL cannot be located as Word 2011 would report.
Office 2016 is sandboxed, with limited entitlements to read files that live in specific places. I wrote this document on installing user content for Mac Office 2016 that you can start with: http://macadmins.software/docs/UserContentIn2016.pdf
Specifically, dylibs must be located in ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/ if they are installed for each specific user, or in /Library/Application Support/Microsoft/Office365/User Content.localized/Add-Ins.localized/ if they are installed once on the machine for all users to share.
Office 2016 apps cannot read arbitrary file locations anymore.
Separately, the inability to choose any non-typelib file when you try to add file references may be a bug. I'll have to take a look.
Schwieb
(Principal Software Engineer, Apple Platform Experiences Group, Microsoft Corporation)
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.
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.