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)
Related
If I build a PowerPoint VBA-Add-in under Office for Windows, will the created .ppam file work under Office for Mac?
I wouldn't count on it.
What will/won't work will depend to some extent on the Mac Office version.
In 2008, nothing will work. There's no VBA there.
in 2011, some stuff will break, and you'll have to write commandbar code for the UI, because it doesn't accept RibbonX.
In 2016, you get RibbonX more or less working, but the app is sandboxed ... you'll be severely restricted in where you can read/write files.
And of course, if you use any Win API calls, they won't work on Mac.
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
An amateur programmer has made a nice little program that works through VBA on top of a MS-Access2010 database. We are asked to make an installer for this database+VBA project. The code runs fine on any computer with Office installed, but on computers without Office we get the error above. On computers without office we install the MS-Access2010 Runtime, which is free, in order to be able to open the .accde file at all. But this does not prevent the VBA error.
I did some research on the issue but did not find anything related to this specific scenario. How can this be troubleshooted?
The problem was a version mismatch between the .accde file (sp1) and the installed ms access 2010 runtime (original) After upgrading the runtime to sp1 all was fine.
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 on windows 7 enterprise
I have infopath 2010 installed my pc and have used it before
But due to my requirements I have to use object model to write code and it requires I add a reference to SharePoint
I read some article but it does not have any solutions for my need (it was on web part and remote debugging, they talked about export the registry and import it to local box)
My question is what do I need to install (bare mininum of SP Foundation or whatever it is) on my local pc so I can develop code and add sharepoint reference in visual studio.
Well the bare minimum is to add the Microsoft.SharePoint.dll (located in the 14 hives folder) to your project - but you are not going to be happy with it. You might be able to write code and the compiler will not complain about missing references but you will not be able to debug or get any information from the SharePoint objects because all information is stored in the specific databases (config db, content db).
The best solution is to install SP Foundation (preferably in a VM) - if you want to code against features which are only available in the Standard/Enterprise version (for example InfoPath Froms Service) you will have to install the correspondig version.