none
WordApplication.Documents.Add Method return null? RRS feed

  • Question

  • why the same code in c# winform run well but wrong in .net web page? the code is 
    --------------------------------------------------------
    object missing = System.Type.Missing;
     Microsoft.Office.Interop.Word.ApplicationClass oWordApp = new Microsoft.Office.Interop.Word.ApplicationClass();
     Microsoft.Office.Interop.Word.Document oWordDoc = oWordApp.Documents.Add(ref missing,ref missing, ref missing, ref missing);
     oWordDoc.Activate();
     oWordApp.Selection.TypeText("This is the text");
    oWordApp.Selection.TypeParagraph();
    object filename = @"h:\\myfile.doc";
    oWordDoc.SaveAs(ref filename, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing);
    ----------------------------------------------------------------------------------------
    the wrong tip is:
    "oWordDoc" is null
    • Moved by Leo Liu - MSFT Friday, May 20, 2011 6:22 AM Moved for better support. (From:Visual C# Language)
    Thursday, May 19, 2011 12:28 PM

Answers

  • If you are able to reference

    System.Diagnostics.

    Process.GetProcessesByName("WINWORD").Count

    That is another way to test if your instance of Word has loaded.


    Wag and they wag with you, Howl and they put you outside. http://greatcirclelearning.com
    • Marked as answer by Bruce Song Tuesday, May 31, 2011 10:22 AM
    Friday, May 20, 2011 1:38 PM

All replies

  • I am moving your thread into the Word for Developers Forum for specialized support. Thanks.


    Leo Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, May 20, 2011 6:23 AM
  • It could be just a timing issue and the code goes forward with executing but Word hasn't fully loaded.

    You could put in a Try or OnError trap and then wait for a second or two and loop. I would suggest adding a check for an instance of Word existing before you try to add a new document.


    Wag and they wag with you, Howl and they put you outside. http://greatcirclelearning.com
    Friday, May 20, 2011 11:21 AM
  •  Does the context in which you run the webapplication have the path h:\\myfile.doc available and writable? Otherwise, it might return null.

    I was experiencing the same exception here in a forms application on Win7 with Office 2010, however mine was not caused by a file IO issue. Somehow the Documents.Add function worked fine the first time, but returned null if I executed it a second time (within the same debug session). The problem was not occurring on older/slower WinXp/Office2003 machines and even not on some of the Windows7/Office2010 machines (with Word 12 and 14 interop), so I ruled out software versions. First I checked if there were no orphaned objects that were causing ghost Winword.exe processes, but that was'nt the case (Clean up your interop objects!). I found it to be some kind of timing issue. Perhaps Word is not yet fully started but somehow the interop can succesfully run the Documents.Add function, even though it returns null and actually does not work. Therefore causing nullexceptions in the code that follows. I know that Windows & .Net use optimization/caching technologies. In my case I suspect that since no optimization has been applied the first time I start the code, the execution order is just right, but when optimizations are in place, the initialization of the Word.Applicationclass is handled quicker in .net than in reality.

    Simply adding a delay between the initialization of Word and the creation of the document seems to be a simple workaround which worked for me. Maybe It'll work for you too. I'm looking for a cleaner solution though, right now I'm just assuming that 1000 ms is enough for initialization.

    Microsoft.Office.Interop.Word.ApplicationClass oWordApp = new Microsoft.Office.Interop.Word.ApplicationClass();

    Thread.Sleep(1000);

    Microsoft.Office.Interop.Word.Document oWordDoc = oWordApp.Documents.Add(ref missing,ref missing, ref missing, ref missing);

     

     


    Jurre Heesbeen

    Friday, May 20, 2011 11:40 AM
  • I just implemented my timing issue solution like this, still need to implement decent error handling in it. I'm still seeing a risk of an infinite loop, but it's a start.

                Document nulldoc = null;
                do
                {
                    document = application.Documents.Add(template, newtemplate, documenttype, visible);
                    Thread.Sleep(100);
                }
                while (document == nulldoc);


    Jurre Heesbeen
    Friday, May 20, 2011 12:00 PM
  • Hi Jurre,

    Put a loop counter into the code and then eloquently end if the counter limit is reached.

     


    Wag and they wag with you, Howl and they put you outside. http://greatcirclelearning.com
    Friday, May 20, 2011 12:05 PM
  • Already in there ;-)
    Jurre Heesbeen
    Friday, May 20, 2011 12:06 PM
  • If you are able to reference

    System.Diagnostics.

    Process.GetProcessesByName("WINWORD").Count

    That is another way to test if your instance of Word has loaded.


    Wag and they wag with you, Howl and they put you outside. http://greatcirclelearning.com
    • Marked as answer by Bruce Song Tuesday, May 31, 2011 10:22 AM
    Friday, May 20, 2011 1:38 PM
  • Please note that with the above solution, you are checking if AN instance of Winword has started, which doesn't always have to be the instance you started. So it might not actually be foolproof within a multi user scenario, or for example when a user is already working with Word and a local application is using the Word interop. Might be that the problem doesn't occur when an instance is already running, no matter if it is the one you are using, but i'm far from sure.
    Jurre Heesbeen
    Tuesday, May 31, 2011 10:51 AM