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.
Related
I am developing an add-in for Word to add ribbon bar functions for our business.
I am developing the add-in in VB.Net using Windows Visual Studio 2017.
The machine is currently a stand-alone machine that is not connected to the main network.
My issue is that for some reason, the add-in seems to have set itself up in such a way that it appears to have already been installed on the system and loads, with the most updated code, if I just start Word normally.
Any development has been done in Debug mode and I have not been re-building the solution in release mode, and yet anything I change and then run/debug updates the code that the add-in appears to be run off when opening Word directly.
If I go through the options --> add-ins and disable the VTSO add-in it just gets enabled again. I don't seem to be able to separate a debug/development section and live code.
Edit from comments: I can accept that the VTSO needs to be installed and registered but having no separation of live code and development code is frustrating. This machine is used by others for other purposes and this includes using Word, and so any old code must be kept as comments that can set back as the working code should I need to leave part way through. I cannot leave anything partially written as any run the debug mode will set the code as live.
What you're experiencing is normal behavior. When you debug, VSTO registers the add-in in the Windows Registry. This is all that's required for the Office application to find and load the add-in when it starts.
If you disable the add-in in Word, it will remain disabled until you again debug the add-in in Visual Studio.
If you share the machine and want to have the add-in under development disabled for other users:
Work with separate user profiles. VSTO registers its add-ins under CurrentUser, not for all users - VSTO isn't designed to register add-ins for the entire machine. OR
Get into the habit of using Visual Studio's Build/Clean Solution functionality when you leave the machine. That unregisters the add-in (until it runs in debug mode again).
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)
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.
I am trying to build a simple addin for Word 2007 using Visual Studio 2010 and .NET 4.0. It's a relatively simple addin, which brings up a save dialog and saves the document as a Word 2003 document.
The addin runs fine in Word under Debug mode, but does not run under Release or when I create a setup project for it. (It does create the registry keys under HKCU\Software\Microsoft\Office\Word\Addins and they look to be correct) I don't get any errors, and the addin isn't listed under the Disabled Addins either.
I tried adding the Addin manually but it says that it isn't a valid addin. The version of Office is 32-bit, running under Windows 7 64-bit.
Or are there even any alternatives to using VSTO (VBA?) that will let me add a tab to the Ribbon?
You can use IRibbonExtensibility interface (http://msdn.microsoft.com/en-us/library/microsoft.office.core.iribbonextensibility.aspx) to avoid using VSTO.