none
How to stop an addin loading if PowerPoint/Excel/Word is being automated or embedded RRS feed

  • Question

  • Hi,

    I have a set of C# VSTO addin's for PPT / Excel and Word 2007, and each of them has a ribbon tab with many functions.  Since these functions are of no use if the Office application is being automated, is there a way of stopping the addin from loading if the application is being automated through COM from another process.

    E.g. We have a Lotus Notes application that automates Word to create letters.  Ideally our Word addin would not load when this happens, as there is a performance impact and we have seen some errors occurring because of it.

    For bonus points - can we do something similar when the office application is running as an embedded object? E.g. stop our Excel addin from loading if it is as part of an embedded object in Word.
    Thursday, August 27, 2009 8:35 PM

Answers

  • Hello,

    I'm sorry for misunderstand your question, do you mean to stop the add-in loading in it self’s Startup method?
    If my understanding is correct this time, we are be able to retrieve the parent process of Office applications, however, we still cannot terminate the add-in from loading in AddIn_Startup method.

    So the solution should be just "return;" from the loading process if the parent process of Office applications is not "explorer”. Please check following code to retrieve the parent process.

    (Please first add reference to System.Management )
     private void ParentProcessUseWmi(int pID)
            {
                ManagementObjectSearcher searcher = new ManagementObjectSearcher("Select * From Win32_Process Where ProcessID=" + pID);
                ManagementObjectCollection moc = searcher.Get();

                foreach (ManagementObject mo in moc)
                {

                    if (mo["ParentProcessID"] != null)
                    {

                        MessageBox.Show(Process.GetProcessById(Convert.ToInt32(mo["ParentProcessID"])).ProcessName);


                    }

                    searcher.Dispose();
                    searcher = null;
                    moc.Dispose();
                    moc = null;

                }
            }


    Call above method like this :ParentProcessUseWmi(Process.GetCurrentProcess().Id)
    For a detailed sample on WMI please refer to this link:
    http://msdn.microsoft.com/en-us/library/system.management.managementoperationobserver.aspx


    Thanks.
     

    Tim Li

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, September 2, 2009 9:28 AM
  • Hi Simon,

    Thanks for point this out, and... after research on this again, I've found if we monitor the process from tools like: Process Explorer(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) the embedded Office application is always started by a process named "svchost", so I think this could be used for us to determine whether it is be embedded.
    Out of this there are not any new findings so far.

    Hope this could help.

    Thanks.

     

    Tim Li

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, December 30, 2009 8:46 AM

All replies

  • Hi,

    Yes, we could stop them, in their Object Model, there's a collection named "COMAddins" which includes all the COMAddins that is installed in this application, then we could stop them by set the Connect property to false.

    Let take Word for example:
    (using Word=Microsoft.Office.Interop.Word;)

      Word.Application application = null;
      if (Process.GetProcessesByName("WINWORD").Count() > 0)
                {

                    // If so, use the GetActiveObject method to obtain the process and cast it to an Application object.
                    application = Marshal.GetActiveObject("Word.Application") as Word.Application;
                }
                else
                {
                   

                    // If not, create a new instance of Outlook and log on to the default profile.
                    application = new Word.Application();
                  }
                  object index = 1;
                  application.COMAddIns.Item(ref index).Connect = false;

    For more information about COMAddIns property please refer to following links:
    http://msdn.microsoft.com/en-us/library/aa432084.aspx
    http://msdn.microsoft.com/en-us/library/aa433287.aspx

    Thanks
     

    Tim Li

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Friday, August 28, 2009 7:09 AM
  • That doesn't quite work, what I am after is not a way of turning them off through automation, but rather a way of setting the addins themselves so that they either do not load, or so they can detect it and not load the ribbon customizations.

    The approach you have shown above only works if the application automating office knows that the addins exist and explicitly disables them, and unfortunately I cannot guarantee that.
    Tuesday, September 1, 2009 7:38 PM
  • Hello,

    I'm sorry for misunderstand your question, do you mean to stop the add-in loading in it self’s Startup method?
    If my understanding is correct this time, we are be able to retrieve the parent process of Office applications, however, we still cannot terminate the add-in from loading in AddIn_Startup method.

    So the solution should be just "return;" from the loading process if the parent process of Office applications is not "explorer”. Please check following code to retrieve the parent process.

    (Please first add reference to System.Management )
     private void ParentProcessUseWmi(int pID)
            {
                ManagementObjectSearcher searcher = new ManagementObjectSearcher("Select * From Win32_Process Where ProcessID=" + pID);
                ManagementObjectCollection moc = searcher.Get();

                foreach (ManagementObject mo in moc)
                {

                    if (mo["ParentProcessID"] != null)
                    {

                        MessageBox.Show(Process.GetProcessById(Convert.ToInt32(mo["ParentProcessID"])).ProcessName);


                    }

                    searcher.Dispose();
                    searcher = null;
                    moc.Dispose();
                    moc = null;

                }
            }


    Call above method like this :ParentProcessUseWmi(Process.GetCurrentProcess().Id)
    For a detailed sample on WMI please refer to this link:
    http://msdn.microsoft.com/en-us/library/system.management.managementoperationobserver.aspx


    Thanks.
     

    Tim Li

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, September 2, 2009 9:28 AM
  • Fantastic - that works a treat, thanks.
    Wednesday, September 2, 2009 5:55 PM
  • This almost works... the problem is that the Parent process is not always Explorer even if the application has opened in full mode.  For example if you launch a file from the internet, or from your mail file, the Parent process will be that application.

    What we need to for there to be some way of knowing that the application is hosted inside another app... any ideas?
    Monday, December 7, 2009 7:00 PM
  • Hi Simon,

    Thanks for point this out, and... after research on this again, I've found if we monitor the process from tools like: Process Explorer(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) the embedded Office application is always started by a process named "svchost", so I think this could be used for us to determine whether it is be embedded.
    Out of this there are not any new findings so far.

    Hope this could help.

    Thanks.

     

    Tim Li

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, December 30, 2009 8:46 AM
  • I'm having the same problem.

    However, I don't want to decide whether to load or not the ribbon depending on the parent process (svchost.exe) since though I saw what you say with Process Explorer, I haven't found any documentation guaranteeing that svchost.exe will always be the parent process when Excel is running embedded or automated.

    Through Process Explorer I can see that Excel is being called by

    "C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE" /automation -Embedding

    Is there any property or condition which depends on "automation" or "embedding" so I can test it and decide whether to load the ribbon or not?

    I'm having some strange behavior in the Addin we are working on when Excel is automated, for example, addin handlers (for example sometimes Application.WorkbookOpen handler is executed before the Me.Startup handler resulting in null exceptions).

    Thanks

    Tuesday, September 28, 2010 4:09 PM
  • Did anyone ever find a resolution to this?  This "/automation -embedding" instance of the application is causing many problems for my VSTO add-in.

    Thanks

    Friday, November 18, 2011 4:49 PM
  • Hi,

    same problem. Looking also for a workaround how determine if word, excel, ppt was started by a user or embedded.

    Thanks

    Best regards

    Mark


    Viele Grüße Mark
    Monday, November 28, 2011 3:09 PM
  • Any answer to this issue? Can I interrogate the workbook for this information?
    Monday, September 9, 2013 8:21 PM
  • If you haven't come across it, yet, see the list of links provided in the "Answer" in this thread (and I hope they're all still available)

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/ffb153b1-5f73-459b-a2e1-d6a4c183f176/determine-via-vsto-if-document-has-been-opened-in-ole-viewer


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, September 10, 2013 9:54 AM
    Moderator