VBA Runtime Error 4160 "Bad file name" when using Document.fullname as index RRS feed

  • General discussion

  • One of my macros runs the following statement:


    (Edit in response to Cindy's first comment below: The actual macro does the UndoClear on a document which is passed as a parameter to the routine which executes it.  I used 'ThisDocument' in the example to provide a simple illustration and means of reproducing the underlying problem).

    It works fine if ThisDocument is on a local or a network drive, but if on a SkyDrive or SharePoint equivalent (as is the case, for example, on my personal SkyDrive or on the Office 365 that comes with my MSDN subscription), it raises a Runtime Error 4160 "Bad File name".

    The problem can be reproduced as follows:

    1. Store a document on SkyDrive that contains the following macro:

    Sub showProblem()
        MsgBox "Press OK to continue"
    End Sub

    2. Open the document from SkyDrive, and choose to Edit it using your local Word.

    3. Run the macro.

    I have circumvented the problem as follows:

    1. A new function finds the numeric index given a FullName:

    Function BWordGetNumericDocumentIndex(xFullName As String) As Long
        On Error GoTo notOpen
        Dim i As Long
        For i = 1 To Documents.Count
            If Documents(i).FullName = xFullName Then
                BWordGetNumericDocumentIndex = i
                Exit Function
            End If
        Next i
        BWordGetNumericDocumentIndex = -1 'in case of failure
    End Function

    2. Where required, replace "Documents(ThisDocument.FullName)" with "Documents(BWordGetNumericDocumentIndex(ThisDocument.FullName))"

    Although I now have a workaround, I hope Microsoft will update the Documents(index) code to prevent the problem occurring in the first place.

    • Edited by Julian Ladbury Monday, September 2, 2013 3:46 PM clarification
    Monday, September 2, 2013 2:28 PM

All replies

  • I don't understand why it would be necessary to use a construct such as you show? Why not simply use ThisDocument.UndoClear?

    Cindy Meister, VSTO/Word MVP, my blog

    Monday, September 2, 2013 3:08 PM
  • Sorry for the confusion Cindy. My actual macro does the UndoClear on a document which is passed as a parameter to the routine which executes it.  I used 'ThisDocument' in the example to provide a simple illustration.
    Monday, September 2, 2013 3:37 PM
  • <<The actual macro does the UndoClear on a document which is passed as a parameter to the routine>>

    So, why wouldn't you simply use UndoClear on this document object?

    Cindy Meister, VSTO/Word MVP, my blog

    Monday, September 2, 2013 3:51 PM
  • Cindy, you have alerted me to a change I need to make, which is that I really don't want to be passing round a Document object. I have encountered problems doing this in the past, and have updated much of my code to pass a document name as a string instead, then access it using Documents(docname).

    The underlying problem remains: if Document.FullName returns a web-like address string, that string cannot be used as a parameter to Documents(). 

    Monday, September 2, 2013 4:04 PM
  • Hi Julian

    In this particular case it would probably make most sense to pass the document object, anyway. FWIW I've never experienced problems with passing document objects...

    Which version of Word are you working with?

    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, September 3, 2013 7:01 AM
  • Hi Cindy,

    The errors which prompted me to pass references to a document name and then use Documents() rather than simply passing a Document object have all been intermittent and not re-creatable to order. Around 2 or 3 customers have reported them in the last couple of years. One of them was running Word 2003 without any Service Pack, and the others were certainly running pre-Word 2007 versions, but it is difficult to be sure of the exact version unless you are at the customer's side! 

    In each case, the error was a Runtime Error 5825 'Object has been deleted'. No code between the first document reference and the error should have destroyed the object. I get the impression from customers that it occurs when a task takes a long while to run, perhaps because of a slow network / large file combination. Perhaps some garbage collection going on, who knows?

    One of the hits I found in an initial search for the problem ( was by no means a direct hit, but it did suggest that the Document object might be a little more vulnerable than it should be, and recommended the approach I have subsequently taken.

    As it happens, I am continuing to pass Document objects much of the time without problem, mainly using the new approach wherever customers have reported a 5825. To have done the extensive amount of code change required  seemed a little over the top.

    Thanks for your interest in the problem.

    Tuesday, September 3, 2013 10:46 AM
  • Hi Julian

    Shouldn't be any "garbage collection" happening in VBA - that's strictly .NET (or Java) and doesn't apply to VBA...

    The article is interesting, and makes a certain amount of sense if you understand how Word handles some things "under the covers". Under certain circumstances it does have to destroy things "in" the document and then recreate them (rather than being able to manipulate the existing object). As time goes on, Microsoft does try to correct these things so that code continues to function.

    I'm having trouble, though, imagining what could delete a Document object from memory, short of closing and re-opening the file...

    URLs/HTTP addresses were historically a problem for Word in respect to document management (opening, saving, etc.). They finally got it fixed as far as the Open and SaveAs methods go. But it looks like they haven't gotten around to doing anything with how the Documents collection handles it - I just checked in 2013 and it exhibits the same behavior. I'll see if I can make the Word team aware of the issue (if they aren't, already), but no chance anything wil change in the immediate future.

    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, September 3, 2013 11:35 AM
  • Hi Julian

    Do the file names to remote drives (URLs) that you're trying to work with contain spaces, by any chance?

    and if you substitute %20 for the spaces do you get better results?

    Cindy Meister, VSTO/Word MVP, my blog

    Thursday, September 5, 2013 1:57 PM
  • Hi Cindy,

    There are some spaces. 

    If I substitute %20 for the spaces I do get better results.

    I updated my test doc as follows:

    The document fullname on the Web is " document fullname property problem with cloud storage.docm"

    This command fails:

    MsgBox Documents(ThisDocument.FullName).Name

    This one works:

    MsgBox Documents(Replace(ThisDocument.FullName, " ", "%20")).Name

    The sad thing, though, is that the situation is reversed on a local document whose name contains spaces, for example

    "C:\Users\julia_000\SkyDrive\Word document fullname property problem with cloud storage.docm"

    In this case, the command 'MsgBox  Documents(Replace(ThisDocument.FullName, " ", "%20")).Name' fails while 'MsgBox Documents(ThisDocument.FullName).Name' works (as you would expect from years of working with local documents).

    It really would be nice if Microsoft would fix this, but as you say I won't hold my breath!

    • Edited by Julian Ladbury Thursday, September 5, 2013 5:24 PM clarity
    Thursday, September 5, 2013 5:21 PM
  • Hi Julian

    Wouldn't all you need to do is first test whether the Document.FullName begins with http and, if it does, run the Replace on it? Make a function from it that returns the correct string...

    Cindy Meister, VSTO/Word MVP, my blog

    Friday, September 6, 2013 2:29 PM
  • Hi Cindy,

    That would work, but I would have a hostage to fortune that no other protocol might emerge in the future. Perhaps if Word were to support ftp file access for example. . . 


    Friday, September 6, 2013 2:35 PM