I have a project that adds functionality to Microsoft Word using an XML Expansion Pack. Currently, when the document we give the customer is opened, it loads our pack, which executes the SmartDocInitialize method which adds things to the main menu and toolbar using Microsoft.Office.Core.CommandBar.Controls.Add and the like. Without modifications, when opened in Word 2007 these buttons are added on the Add-Ins ribbon tab, but this isn't ideal since the buttons are all small, not grouped properly, and there is no way to bring the Add-Ins tab to the front when the document is loaded.
I would like to keep this functionality the same if the document is opened in Office 2003, but if the document is opened in Office 2007, I would like to read in an xml file which describes my new Ribbon tab and all of the buttons. Everything I've been able to find online has seemed to lead to the Ribbon file only being loaded if you have a very specific combination of magic (build in Visual Studio and it works, but no information on how you would deploy it to a users box) and will only work if you have an entire project created originally with the Visual Studio tools for Office properties, which I don't currently have.
Our development environment is XP, Visual Studio 2005, C#, .NET 2.0
The Ribbon UI is just not as programatic as the old CommandBars UI. I don't think you can do what you want. As far as I know the only way to programatically modify the Ribbon UI is to have a (COM) Add-in implement the IRibbonExtensibility interface and return a custom XML file (with the Ribbon definition) from the GetCustomUI method. There is no way to add or remove buttons one at a time like you could with the CommandBars UI. It's just totally different. I don't believe you can do what you want from some macros in a document.
I'm not familiar with XML expansion packs, but if you have to install them on the user's PC, perhaps you could install an add-in as well that could load the appropriate ribbon XML for you.
This isn't as hard as it seems.
If you already have your ribbon buttons hooked up to some VBA macros in the document, then you just need to add a reference in your VBA project to your com visible .net assembly.
The .net assembly in addition to being marked com visible (so it shows up as a type library in the references dialog box), has to have some methods that are setup to be callable from VBA.
google "vba .net callable"
its not difficult, mark class as com visible, declare it with a ProgID attribute, make methods public, make sure your methods return simple types, and use regasm to register the assembly on the target machine (not needed on dev box).
Related
I need to deploy an add-in to Outlook. I have a old VBA macro that works, (save an Outlook item do pdf). But I need a modern way to deploy it to all users. Is it possible in Visual Studio Windows Form? There is a template?
You can use any .net components for getting the job done if you develop a COM add-in (for example, a VSTO based one). Basically, you may get the HTMLBody property value and save it using the .pdf file format. See Convert HTML to PDF in .NET for more information.
Take a look at the Walkthrough: Create your first VSTO Add-in for Outlook article to get started quickly.
Office Ribbon buttons and other commands can be "re-purposed" using XML and onAction method. I have already done that successfully. Is there an equivalent C#/Object Model way of doing it too? Google hasn't shown much promise.
Background: The main Ribbon of my add-in is using visual designer. If I use the XML method of re-purposing, my main Ribbon will not be loaded. Other than this road bump, I'm interested in finding the solution in general too.
After spending some time, I learned that there is no way of doing this from C# code. I must switch to XML Ribbon approach. Fortunately the Visual Designer can help you translate your existing ribbons into XML format. You can right-click the Ribbon in Visual Designer and choose "Convert to XML" command.
I also found that XML Ribbon approach is far more powerful in the sense that it can access Office 2013 and 2016 features that the Visual Designer cannot. For example the Office Backstage and new context menus are only accessible in XML approach.
I want to know anybody knows if there is in VSTO a control or a way to create a popup like Quick Analysis that appears at the right-bottom of a given range:
I'm creating an Excel plugin in VS2013 with C#, the plugin should be compatible on Excel 2007, 2010 and 2013. If such control can only be created on the latest version of Excel (2013) that may not be an option for deploy. I´ve already created a traditional Windows form to do this, but I'll like to know if there are better ways to show new controls to the user, closer to where the action is occurring. Thanks!
I am new to Visual studio for office (VSTO)
I am using VSTO to create an addon for PowerPoint, Word and Excel. The ribbons (UI) look-and-feel will be the same for the addons. Here is my question:
How can I set up the visual studio such that I use only one code base for these addons and reuse Ribbon UI; or must I creates separates solutions each for PowerPoint, Word and Excel?
Out of the box it is pretty hard to achieve what you are after.
If you use the VSTO Contrib project's Ribbon Factory you can reuse the ribbon viewmodel's between all of the add-ins pretty easily I think.
http://vstocontrib.codeplex.com/
In addition, I would then manually go and edit your .csproj file of the shared project to conditionally include specific references so you do not have all the office interop libraries referenced at once.
How does Excel VSTO Work? If I create an Excel Workbook solution in Visual Studio 2005 I can then happily code away with full access to the Excel object model and even treat the Excel sheet as a design surface. When I build the solution I get a .XLS file and a .DLL (containing my C# code).
I can now start up the Excel sheet just by double clicking on the .XLS and there is my sheet functioning with all my C# code and any controls I dropped on the sheet etc.
How is the sheet referencing the .DLL? What part of the excel workbook/sheet tells it that it needs to fire up the CLR and host my assembly?
According to this (thanks PintSizedCat) for Excel 2003 the following happens:
The Microsoft Office application
checks the custom document properties
to see whether there are managed code
extensions associated with the
document. For more information, see
Custom Document Properties Overview.
If there are managed code extensions,
the application loads AddinLoader.dll.
This is an unmanaged DLL that is the
loader component for the Visual Studio
2005 Tools for Office Second Edition
runtime. For more information, see
Visual Studio Tools for Office Runtime
Overview.
AddinLoader.dll loads the .NET
Framework and starts the managed
portion of the Visual Studio Tools for
Office runtime.
The Visual Studio Tools for Office
runtime creates an application domain,
sets policy for the application domain
not to trust the My Computer Zone, and
checks the code access security policy
store to find a policy for the
customization assembly.
The .NET Framework validates the
evidence presented by the assembly
against the policy. If it fails, an
error is raised. If it passes, the
process continues.
If the customization uses a deployment
manifest, the Visual Studio Tools for
Office runtime uses it to check for
assembly updates. If any updates are
necessary, they are performed now.
The Visual Studio Tools for Office
runtime loads the assembly into the
application domain.
The Visual Studio Tools for Office
runtime calls the Startup event
handler in your customization
assembly. For more information, see
Visual Studio Tools for Office Project
Events.
In my test project's Excel workbook I have two custom properties:
_AssemblyName, value = *
_AssemblyLocation, value = {533b2c13-a125-418a-bfff-9546b0762807}
I suppose these are the properties which direct the VSTO runtime to my assembly.
This is all done in the Registry, you should be able to find the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel or your equivelant application. I've more experience with COM Addins which are registered somewhere else in the Registry as well. This key should have a LoadBehaviour item under it which is used to determine how the application is loaded (2 is load manually, 3 is load automatically on startup).
Do you have a Setup Project for your VSTO? Inside there you can see the Registry key that is set, but the Setup program will/should also Register the VSTO in GAC (though don't take my word for it as I'm a bit shakey with VSTO as I said).
Hope this helps, I shall try and find some more information for you.
Edit
You should try reading the following http://msdn.microsoft.com/en-us/library/bb386298.aspx which will give you an explanation of what the addin is. It's really just a wrapper around a COM host which is loaded from the Registry and the VSTO talks to that using some Interoparability code.
Also useful are http://msdn.microsoft.com/en-us/library/23cw517s.aspx (Getting Started with Visual Studio Tools for Office, don't knock it because it says Getting Started in, there's a lot of useful info in there) and http://msdn.microsoft.com/en-us/library/hy7c6z9k.aspx (Which is linked from the first and is an overview of VSTO Addins).