In my workplace we have several different types of systems.
Surface Pro's running Office 2016
Surface Pro's running Office 2013
Thin Clients running Office 2010
Desktops for Accessibility users running Office 2010
I develop VBA solutions that have to work across all of the above, and run into trouble with only one scenario.
I use a Surface Pro with Office 2016. If I build a document, I can run the macros I create on the Surface Pro's and Thin clients without issue, but the Desktop PC's running Office 2010 don't even get the option to turn on the macros.
If I open the file up on a desktop (seldom have access to one) and save it using that system, any other user on a desktop can open it up and the macros will work, but if anyone from one of the other systems opens it up and saves it, the desktop users will go back to square one.
At first I thought this would have been a compatibility issue relating to architecture
Can anyone think of anything before I pull the remainder of my hair out? I really want to be able to solve issues for the people having problems on desktops without having to find one myself, or worse - give them any passwords
Cheers
Go to VBA Tools and uncheck all objects marked as missing under References.
Related
Happy New Year everyone!
I'm building an Outlook Add-in (non-web), and it works really good at home (Office 365/2016). At work, I have office 2013, and some features don't work very well on it. So, since I have VS2017 on both computers, and my code is on Azure, I can go ahead, and download it, run it, and it should work, however I get the error that I can't debug it because of the version difference.
So, After digging around the net, the most popular answer was tell the add-in to run by giving the path to this version of outlook. The problem with this, is that I'm not able to hit break points, etc.
Now that you have some background, here is the problem I have and the question I need answered. Is there a definitive guide or best practice to allow me to 'debug' as well as test my add-in across different office platforms, or, is there a way to adjust the code/package to allow me to debug on any office platform out there?
Thanks for the help.
We build many office application for windows, and it work very natively with office UI but when we came to do same on office for mac we have been lost :(
We need an embedded native Microsoft word for MAC 2016 (better if works with Microsoft word for mac 2011 too)
*by native we mean to be embedded in word window, not like the VBA forms, like word panels etc
*The most important issue for us is the UI and how it will work like if it was built by Microsoft it self,
*ANY SOLUTION FOR MS-WORD FOR WINDOWS IS NOT WHAT WE ARE LOOKING FOR AT ALL, THE SCOPE IS MICROSOFT WORD BUT FOR MAC
*The UI we prefer first is something like word native pans such as
*Navigation pane
*Task pane
*Side bar/pan
if this not possible then 2nd option will be
*Ribbon
if this not possible then 3rd option will be
*Toolbox
We open to use any technology to build this, such as VBA,swift, objective-c whatever provide us with the solution we need,
Any advice??
As far as I am aware, the support for embedding native clients is going the way of the dodo. Everything is moving towards the Office Web Apps and embedding that view within applications. It might make sense to review if that allows for the functionality you are looking for based on how it's deployed.
Background:
I have come up with an idea that will make things easier for the company I work for. They even seem excited about the idea. The idea is to make an addin for Outlook to help with a task. So after doing a bit of research (obviously, not enough). I downloaded a trial copy of VS2010 pro and created a VSTO addin.
After creating the addin, it was time to package it for a small test deployment. That's when I found out that this is a much more difficult thing to do. It seems MS does not ship Office 2010 with the runtime needed to run VSTO, so i'd have to package that as well. In a company environment, this is not something simple to do.
So, I might have to go back to the drawing board.
Meat of the question:
I've never created an addin for office before, I really want more of a "drop in" solution. I'm not sure if VBA is the right solution. It seems more of a "document" level application (or macro?). Does any one know what would be the best type of solution for this?
Outlook API is not native .NET framework. To interact it with, .NET relies on marshaling and interrop assembly thus making it much more prone to errors and unstable.
From what I've seen so far with my outlook API experience, I would stick with VBA and you should consider retrieving a third party library that exposes outlook extended MAPI if you run in to much of trouble.
NetOffice is pretty good - it is a set of managed .NET libraries that handles the COM API with Office and only needs XCopy installation.
The best part is it tracks all runtime callable wrappers ('RCWs') you create when accessing objects through COM and automatically releases them when you dispose the top-level object (the Application in most cases), so you won't get the issue of an orphaned COM 'handle' preventing you from closing Office.
Alternatively, the Office Primary Interop Assemblies should be on any computer that has the relevant version of Office installed (at least for >= Office 2007). But there are cases when it won't so you will have to cover that possibility. VSTO redistributable should already be installed on any computer with Office 2010 or 2013. For Office 2007 you will need to install it. But again, better safe than sorry so you should include it in your installer in both cases.
For details on deployment options look at http://msdn.microsoft.com/en-us/library/bb386179.aspx
As for VBA, I don't have experience for Outlook addins so I leave that to others to explain. Other VBA Office app addins (Excel/Word/Visio/PPT at least - not sure about the others as I haven't used them) can be installed either using registry keys or through XCopying the addin to a trusted location and then telling the user to open Options/Manage addins and tick the tick box.
I highly recommend Add-in Express. They have tools that go beyond what Microsoft provides via Visual Studio.
Their features for Outlook development greatly reduce the amount of effort required to build Outlook add-ins
I work in an academic lab, and have been working on VSTO Add-In to Excel (primary to handle complex data analysis and generate reports, what I think is bread and butter for VSTO). At the lab we have Office 2010 almost exclusively (universities are like that). We are partnering with a drug company that is using Office 365.
They want to use the same Add-In I've been developing so we're all on the same page. I've let our Tech Transfer office know in case there are any licensing issues, as I don't think that's my problem to figure out.
On the tech side of things, I've been trying to figure out if the Add-In will work with 365. I built it in VS-2012 (academic version of professional) and it works well in Excel 2010 (though I keep adding to it).
I have read:
https://blogs.msdn.com/b/donovanf/archive/2011/06/29/office-365-developer-guidance-and-resources.aspx?Redirected=true
Which didn't make it sound hopeful, until I realized that if they get the premium edition it still includes a local install:
https://office.microsoft.com/en-us/business/office-online-microsoft-office-365-for-small-businesses-FX103037625.aspx
So my question is if someone is using the 365 Premium Edition with a local instal, then will a VSTO built for 2010 still work? I may be able to answer this in a few days when I actual meet them in person (and thus try it out), but I'd like to know the answer ahead of time if possible.
If not, would the best solution be to back track into VBA (that seems backwards) or try to work with SharePoint (for the first time in my life).
Thanks.
Well hopefully, someone can save some worry by knowing that infact it will work with Premium addition of 365. I was able to deploy the add-in without issue to their 365 local installs. I don't think it will work with the lower versions, but I haven't had a chance to test that yet.
I'm looking for some advice from anyone who has experience writing addons for PowerPoint on both Windows and Mac machines.
We have a Windows Office 2007 addon (.NET) that we'd like to port to the Mac.
Thus, in PowerPoint 2008 for the Mac, we require the following functionality:
Ribbon/Fluent extensibility
Custom Task Panes
Read/write custom document properties
Save slides as images
Read text and shape information from slides
Get notification of the following PowerPoint application events; `SlideSelectionChanged`, `PresentationClose` and `AfterPresentationOpen`.
I am hoping someone with experience writing Office addons for Windows and Mac, can advise.
This doesn't solve your problem if you need to specifically do this in 2008, but Office 2011 is coming and it brings back VBA. Spending the effort to convert your stuff to AppleScript might be a lot of work for little return where you could wait for Office 2011 which brings the Ribbon to Mac Office as well as VBA...
http://www.computerworld.com/s/article/9085678/Microsoft_will_bring_back_macros_to_Mac_Office_in_2011