Bad File name (2010) but good in 2007, 2003, ...

[ChrisGreaves]

Has Office2010 changed the rules about Documents.Add?

Code: Select all

Sub Labels()
    Documents.Add Template:=ThisDocument.Path & "\" & "MMC Shipping Labels.dot", _
        NewTemplate:=False, DocumentType:=0
End Sub

I upgraded the code for a client's client.
I used ThisDocument.Path & "\" in place of H:\Templates\Word\

The upgraded code works fine on my Win7HP/Office2003 Notebook.
The upgraded code works fine on my Win7SE/Office2007 Netbook.
The upgraded code fails on my client's client's new Win7/Office2010 machine.

And I am ashamed/sorry to say that I was so flustered last night that I neglected to take a PrtScr of the screen, or to note the run-time-error in full.
The RTE was along the lines of "badly formed file name", I remember that, because I dropped into the Immediate pane and interrogated the value of ThisDocument.Path & "\" & "MMC Shipping Labels.dot" .
It looked fine.
I wrapped it in a FileLen() function and got back a value of about 32,000, which seemed reasonable to me.
So that FileLen accepted the name but Documents.Add didn't.
I tried removing the space in the file name (both in Explorer and in the VBA code). Same error.

The only thing I can think of is that Office2010, unlike Office2007, requires a dotX extension, but this morning I have no easy way of testing that theory.

[Don Wells]

Just a guess but:

• Is the 2007 machine running in compatibility mode? I would wager; Yes.
• Is the 2010 machine running in compatibility mode? I would wager; No.

[ChrisGreaves]

Just a guess but:

• Is the 2007 machine running in compatibility mode? I would wager; Yes.
• Is the 2010 machine running in compatibility mode? I would wager; No.

Hi Don.
:clutchingatstraws: here.
I do recall seeing something about "Compatibility Mode" on the title bar on the client's client's machine.
I can see "Compatibility Mode" on the title bar of my Win/SE/Office2007 netbook.

"Plan for using compatibility mode in Office 2010" and "http://technet.microsoft.com/en-us/libr ... 12%29.aspx"

If the client's client is in Compatibility Mode, then, the theory is, that that system should behave just like my Office 2003 system, at least in standard/vanilla VBA constructs like "Documents.Add".

But if the client's client machine was NOT in compatibility mode, then perhaps Documents.Add would balk at being asked to use a 2003 template to institute a 2010/XML document.

Is that your feeling?

(I am about to email my client asking for a second shot this eveneing, at which time I will log screenshots of all RTEs)

[Don Wells]

Is that your feeling?

You have it in one, Mother Brown.

[StuartR]

This won't resolve your problem, but it would be better if you replaced "\" in your code with Application.PathSeparator

[ChrisGreaves]

This won't resolve your problem, but it would be better if you replaced "\" in your code with Application.PathSeparator

Hi Stuart.
I remember that.
I used Application.PathSeparator for years until i found that porting utility code to Excel or Outlook or Project broke because (one of them)/they didn't support it.

I agree wholeheartedly with the avoidance of literal constants within procedure code, but in this case i figured that MSoft wasn't going to change.
Ever!

[HansV]

How about

Code: Select all

    Dim strPath As String
    strPath = ThisDocument.Path
    If Right(strPath, 1) <> "\" Then
        strPath = strPath & "\"
    End If
    Documents.Add Template:=strPath & "MMC Shipping Labels.dot", _
        NewTemplate:=False, DocumentType:=0

If ThisDocument happened to be stored in the root of C:, ThisDocument.Path would be C:\ and ThisDocument.Path & "\" would result in C:\\ which is clearly not what you'd want. The above code works around that.

[ChrisGreaves]

If ThisDocument happened to be stored in the root of C:,

Hi Hans. Welcome back!
Your statement ("better code") is correct, but I feel that can't be a cause of the problem because the template set were installed into a folder \20110519\ on the desktop.

My Immediate Pane display of the constructed file name showed a path that was not the root.

Your augmented code should be implemented against the day when someone does install the templates into C:\ or some SUBSTituted drive letter.

In the meantime i have to get back onto the machine(s) and make a better note of the RTS codes and messages.
I was too flustered/tired the other day.

[rory]

FYI I just tested your code while not in compatibility mode and it ran fine. I assume you can manually create a new doc based on that template?

[ChrisGreaves]

FYI I just tested your code while not in compatibility mode and it ran fine. I assume you can manually create a new doc based on that template?

Rory, thanks for supporting my client's client (grin!).
I'm (sort of) glad to hear that the code ran.
It's the level of VBA code that I would expect to run anywhere.

I didn't think to try creating a new document (manually) on the template.

We have another test run scheduled for this afternoon, and I'll log in to that with a script of things to try.

I mentioned before that I was flustered. Here is the sort of code I've written and used for years. Tested on two systems here, crashes there.
To make matters worse, the screen resolution was very poor. I rather suspect I was going through TWO levels of GoToMeeting, or JumpIn, or whatever the remote access software is called.

[ChrisGreaves]

FYI I just tested your code while not in compatibility mode and it ran fine. I assume you can manually create a new doc based on that template?

Rory AND Don:
Thanks.
I took snapshots last night.
As far as I can tell Run-time error '5981' and '5460' can be brought about be something called "Protected View" which status appears in the Word caption/title bar along with "Compatibility Mode".
The trust center, if one digs deep enough, brings up a screen with three check boxes for "Protected View"and one check box for "Data Execution Prevention".

We checked OFF all four check boxes and the problem went away.

We were trying to create a new document based on a template.
That template had been unzipped from a zip file.
That zip file had been emailed to my client, who had unzipped it onto his client's machine.
We were using his client's machine.

It is possible that Win7 keeps track of the heritage of files in a manner that could become quite annoying, (unless a scan by MSE flags the file as safe.)

mmc_005small.png

[HansV]

When you download a file from Internet or save an attachment from an email message, it's a good idea to right-click the file in Windows Explorer and to select Properties from the context menu. In many cases, you'll see an Unblock button near the bottom of the dialog. If you see it, the file has been marked a potential risk. Click the Unblock button to mark the file as safe.

unblock.jpg

[ChrisGreaves]

... you'll see an Unblock button near the bottom of the dialog.

neat-Oh!
Thanks Hans.
I'd seen the button before but my brain had registered it as "UnLock", as in Unlocker.
I'd rather UnBlock than loosen security on a client's client's new system ...