Is it possible to handle button click events on a custom ribbon button from another application using interop?
So if I've created a Word 2010 application add-in which creates a custom tab with several buttons and then I instantiate a Word application from a C# win forms application using interop, how would I then go about wiring up to the button click events on my custom ribbon from the win forms app? With Word 2003 I could access the buttons through the CommandBars collection and then simply wire up to the click event.
After some further reading, I guess what I'm trying to do is find out how to get access to the Ribbon object model using interop. Is this possible?
[Edit]
For anyone that's interested. When I wrote this question I knew of another way to solve my problem, but it means a lot of extra work changing my existing implementation to upgrade from Office 2003 to Office 2010, and so I was hoping there would be away to access the Ribbon object model outside of a VSTO add-in.
My solution is to use an IpcChannel to make calls from the vsto add-in to my win-forms application. So my win-forms application initialises the Word instance and then opens up a server channel. In the vsto add-in I handle Application.DocumentOpen and if the document is owned by my application I open a client channel to my application. I can then make calls back to my win-forms app from the vsto add-in through the use of shared interfaces.
While this technique works, it does have some draw backs. If the calls through the ipc channel are synchronous then my application can't touch the word object because a deadlock occurs. Making asynchronous calls introduces other problems, but I found that I could block the Word window with a modal dialog without ending up deadlocked.
While this isn't an exact answer to my original question, it is an alternative and so I thought I would share this with anyone else having this problem.
If anyone does know how to access the Ribbon object model outside of VSTO I would still be interested to know how.
Edit: I finally discovered a code.msdn.microsoft.com project that incorporates native C# ribbon manipulation. Use that instead of any VBA business.
Original Post:
You don't need VSTO to access the ribbon programmatically. Visit Word Articles for a brief Word VBA example.
I'm certain there's a way to accomplish the same in C#, but I have yet to implement one. If I find one, I will be certain to share. (I previously contributed an answer that contains a C#-VBA workaround.)
Related
I have created a C# VSTO add-in with Visual Studio 2019 that receives commands from a socket connection and it can insert text, modify buttons only in my ribbon using office Interop.
I want to know two things.
How can I get the name of all the ribbons (Home, Insert, Design,
....) programmatically?
Initiate a mouse click (for example click Bold button in the Home tab) on any other ribbons than the one I created.
For the 2nd question, I want to use office add-in only, not by simulating keypress/mouse event.
How can I get the name of all the ribbons (Home, Insert, Design, ....) programmatically?
There is no trivial way for getting this job done. You can try using Accessibility API. Microsoft Active Accessibility is a Component Object Model (COM)-based technology that improves the way accessibility aids work with applications running on Microsoft Windows. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and API elements that provide reliable methods for exposing information about UI elements.
Initiate a mouse click (for example click Bold button in the Home tab) on any other ribbons than the one I created.
You can use the CommandBars.ExecuteMso method which executes the control identified by the idMso parameter. This method is useful in cases where there is no object model for a particular command. Works on controls that are built-in buttons, toggleButtons, and splitButtons. On failure, it returns E_InvalidArg for an invalid idMso, and E_Fail for controls that are not enabled or not visible.
Application.CommandBars.ExecuteMso("Copy")
Accessibility API (as Eugene mentioned) is pretty much the only way to drive Outlook Ribbon and its controls. Keep in mind that since Microsoft has never documented the controls and their ids, they are subject to change between the versions.
If using Redemption (I am its author) is an option, it exposes SafeExplorer and SafeInspector objects that expose the ribbon and its controls using Accessibility and low level Windows API.
Redemption.SafeExplorer sExplorer = new Redemption.SafeExplorer();
sExplorer.Item = OutlookApplication.ActiveExplorer;
foreach (var tab in sExplorer.Ribbon.Tabs)
{
MessageBox.Show(tab);
}
I am trying to access the ribbon of Microsoft office word file using C#. and trying to change its visibility inside a background worker. Please help
By design, this is not possible. An Office Ribbon can only be controlled from code running in-process in the host Office application. What's more, the Ribbon definition must be part of the "container" of the code that's should affect the Ribbon.
This was a conscious and desired design decision by Microsoft after the experiences it has with the Ribbon predecessor - the CommandBars object model.
I need to create an outlook extension which should have a form with two buttons, and it should appear on the right side of the application, like how the todoist app does(red circled in the screenshot).
I tried creating using the "Outlook 2013 Add in" project type, I was able to create an add-in with some basic functionality, but did not know how do add a UI to it.
On little more googling, I found this, this looked like what I needed but didnt seem to be officially from microsoft/visual studio and appeared to be with some kind of fee too.
I am trying to make my first outlook extension.
Couldnt get any good results when I tried googling for the same, can anyone guide me in this ?
VSTO (nor Outlook) doesn't provide such layout for custom forms. However, you are free to use Windows API functions to subclass the Outlook window and inject your own forms. They call them as Adjacent Windows In Outlook. See the Creating Adjacent Windows In Outlook sample code.
Add-in Express uses the same technology for subclassing Outlook windows. As a result you get a convenient way to place .net controls on a Windows form. For example, I have just tested a sample add-in with an advanced Outlook form placed to the RightReadingPane layout. And here is what I get:
I'm currently writing a PowerPoint 2010 C# add-in using VSTO. I am trying to execute a number of Ribbon controls which are there through custom add-ins from within my own C# add-in.
For example, to find the following control and execute its click event, how would I do it?:
Insert tab -> "Addin X" group -> "Do it" button
I've looked into using the Accessibility interface but am totally unfamiliar and would be at it all day. If someone knows how to knock together the code, I would be immensely grateful.
Short version: what is the preferred approach for embedding controls in a PowerPoint slide that send events back to an application-level add-in? The controls need to work in slide show mode and in design mode.
Long version:
I recently was brought into development on a legacy add-in for PowerPoint that (in a nutshell) pulls data from remote data sources and draws corresponding charts on slides. The add-in is managed code (C#), but is NOT built with VSTO - it uses custom wrappers and a COM shim.
The charts periodically need to be refreshed, and our add-in has a Refresh button in the toolbar for this purpose. In cases where a chart can't render at all until refreshed, we also embed a MSForms.CommandButton on the slide itself (as an OLE object). We have used this approach in a similar Excel add-in with success.
Unfortunately, it does not work in PowerPoint: the click event on the button does not seem to reach our add-in. I have found some information online that supports this observation. I have also tested it with a MSForms.ComboBox instead of a button and that worked--the combo box's change event reaches our add-in and the refresh succeeds.
So it seems that I need to find an alternative way to have the button communicate with our add-in. I can think of a few approaches and am wondering if there is a best practice:
Have the button (or a similar shape) run a macro that calls code in our add-in. I've heard that this might not work when the slide is viewed in Design Mode, but haven't tested yet to confirm.
Embed an MSForms form in the slide as well, to capture the click event and pass it on to our add-in. Again, this is just a theory and is untested as of yet.
Use something else entirely - something tells me there has to be a "modern" way of doing this, I'm just not familiar enough with Office development to know what that is.
I'll add that migrating to VSTO or a similar technology (such as NetOffice) is an option, but we'd prefer to avoid that if possible. Thanks!