none
Prevent the file open dialog from appearing for Interop.Word? RRS feed

  • Question

  • Hi,

        Are there any methods which can prevent users from using the open file dialog from Interop.Word.Application GUI? Because I want the users to view the files by using the Interop.Word.Application.Documents.Open() method only.

        In fact, my target is to prevent the users from accessing a "real" file explorer by using the file dialog. I have successfully blocked the save file dialog by using the Interop.Word.Application.DocumentBeforeSave event, but I don't know what to do with the file open dialog...

    Friday, January 18, 2013 7:34 AM

Answers

  • Hi Tim Tong

    Thank you for the additional details :-)

    In Word's object model Add-ins based on IDTExtensibility2 are termed "COMAddins". What Word "sees" as a Com Add-in is determined by the Windows Registry - a COM Add-in must be correctly registered in order for Word to be able to pick it up and load it. 

    On your development machine, this will be taken care of by VSTO when test in debug.mode. It will remain registered and can be used from within Word even when Visual Studio isn't running. You should see it in the list of COM Add-ins (there's a button in the Developer tab on the Ribbon).

    In order to install the add-in on other machines you need to "Publish" it. I'm assuming you'd distribute it with your main program. For more information about publishing and deployment, please ask in the VSTO forum (http://social.msdn.microsoft.com/Forums/en-US/vsto/threads/).

    A COM Add-in can be registered to load automatically when Word starts (default) or on-demand, which is what you'd want.

    Your external process has an object for the Word application, yes? (Word.Application wdApp = New Word.Application(); for example)

    You can loop through the COM Add-ins registered for Word:

       foreach (Word.ComAddin adin in wdApp.ComAddins)
      {
            System.Diagnostics.Debug.Print(adin.ProgId + ", " + adin.Connect.ToString());
       }

    The Connect property indicates whether the Add-in is currently loaded (true=yes, false=no).

    The ProgId can be used as an index value to address the add-in. Once you know what it is (usually the name of the VSTO solution), you can use that to address the add-in directly, without needing a loop. So, for example:

      //Is the add-in loaded?
      //If not, load it
      if (!wdApp.COMAddins("ProgId").Item.Connect)
        wdApp.COMAddins("ProgId").Connect=true;

      //Unload the add-in because the out-of-process app using it is finished
      wdApp.COMAddins("ProgId").Connect=false;


    Cindy Meister, VSTO/Word MVP, my blog


    Tuesday, January 22, 2013 8:16 AM
    Moderator

All replies

  • Hi Tim

    There might easily be an easier way of doing this, but here is how I control the "Open" trigger in Word

    First off, I have disabled all the shortcuts for opening the "Open dialog"

    Secondly, I'm using a win32 keyboard hook to capture the input from the user - in regards to the "Open" dialog, I'm using "ctrl+o" and "ctrl+F12", here calling a customemade "Open" method, displaying my own winform

    Last, I'm using a custom Ribbon, where I'm poiting the "Open" action from the "open" button click, to my own custom "Open" method as well

    Like I said, there might be some easy-fix event you can catch that will make all of the above obsolete, I just haven't been able to find it :)

    The best of luck to you

    /RKR

    Friday, January 18, 2013 8:12 AM
  • Hi RKR,

        It seems to be quite difficult...

        1. How can I remove the "Open files" function from the Ribbon, and prevent the users from adding them back?

        2. I am using WPF to develop the solution. How can I override the built-in shortcut keys in Office?

    Tim

    Friday, January 18, 2013 9:27 AM
  • Hi Tim

    If you're controlling Word out-of-process, as seems to be the case, then you have little to no control over the user interface. This is by-design. An add-in is required that provides a Ribbon customization in order to re-purpose and/or suppress commands.

    Your project could include a VSTO or Shared Add-in (an Add-in that implements IDTExtensibilty2) or a Word template add-in. When your project is in use it can load the add-in and when it's done, unload the add-in so that it doesn't interfere with the user's "everyday" use of Word.

    If all you need to do is suppress commands, you create a Ribbon XML customization with a <commands> section, one <command> for every built-in command you want to control. For opening documents, for example: <command idMso="FileOpen" enabled="false" />


    Cindy Meister, VSTO/Word MVP, my blog

    Friday, January 18, 2013 10:52 AM
    Moderator
  • Hi Cindy,

        The solution you have provided seems promising! =]

        Since I am a complete newbie in Office programming, would you kindly provide some reference links such that I can find more detail?

        P.S. I have found some resources and can disable the file open function, but have no idea about how to load and unload the addin within my WPF code...

    Tim


    • Edited by Tim Tong Monday, January 21, 2013 3:25 AM
    Monday, January 21, 2013 1:32 AM
  • You need to provide information about what kind of Add-in you've constructed?

    Cindy Meister, VSTO/Word MVP, my blog

    Monday, January 21, 2013 4:36 PM
    Moderator
  • I have used Visual Studio 2012 to create a new Word add-in project, add Ribbon XML and then add

    <command idMso="FileOpen" enabled="false" />

    to it. It functions perfectly to disable the file open.

    But, in the bin folder I can find some DLLs and a VSTO file, don't know how to make use of them... :S

    Tuesday, January 22, 2013 1:23 AM
  • Hi Tim Tong

    Thank you for the additional details :-)

    In Word's object model Add-ins based on IDTExtensibility2 are termed "COMAddins". What Word "sees" as a Com Add-in is determined by the Windows Registry - a COM Add-in must be correctly registered in order for Word to be able to pick it up and load it. 

    On your development machine, this will be taken care of by VSTO when test in debug.mode. It will remain registered and can be used from within Word even when Visual Studio isn't running. You should see it in the list of COM Add-ins (there's a button in the Developer tab on the Ribbon).

    In order to install the add-in on other machines you need to "Publish" it. I'm assuming you'd distribute it with your main program. For more information about publishing and deployment, please ask in the VSTO forum (http://social.msdn.microsoft.com/Forums/en-US/vsto/threads/).

    A COM Add-in can be registered to load automatically when Word starts (default) or on-demand, which is what you'd want.

    Your external process has an object for the Word application, yes? (Word.Application wdApp = New Word.Application(); for example)

    You can loop through the COM Add-ins registered for Word:

       foreach (Word.ComAddin adin in wdApp.ComAddins)
      {
            System.Diagnostics.Debug.Print(adin.ProgId + ", " + adin.Connect.ToString());
       }

    The Connect property indicates whether the Add-in is currently loaded (true=yes, false=no).

    The ProgId can be used as an index value to address the add-in. Once you know what it is (usually the name of the VSTO solution), you can use that to address the add-in directly, without needing a loop. So, for example:

      //Is the add-in loaded?
      //If not, load it
      if (!wdApp.COMAddins("ProgId").Item.Connect)
        wdApp.COMAddins("ProgId").Connect=true;

      //Unload the add-in because the out-of-process app using it is finished
      wdApp.COMAddins("ProgId").Connect=false;


    Cindy Meister, VSTO/Word MVP, my blog


    Tuesday, January 22, 2013 8:16 AM
    Moderator
  • Thanks a lot!

    Let me have a try first...

    Wednesday, January 23, 2013 1:15 AM
  • Hi Tim

    My brain must have been falling asleep when I typed the lines of "sample code" yesterday evening. Note the changes I made (put the indexer after the collection object instead of after the property). Sorry about that!


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, January 23, 2013 1:02 PM
    Moderator