Pickle of a problem: Autoopen and 4160 Bad File Name

[wadiohead]

Hi all,

I apologize in advance about the information I can't provide here--believe me, it's out of my control.

SETUP:

I'm using AutoOpen to scan documents opened by a proprietary, web-based document-tracking system. The system opens up the document from IE (I assume via some sort of ActiveX magic); the document opens in Word, not in Internet Explorer.

PROBLEM:

Part of their package is a Word macro (password protected, of course) that allows for the uploading of documents back to their server. Occasionally, under what seems to be absolutely arbitrary times with no identifiable causes, this upload macro causes a "4160 BAD FILE NAME" error and fails to upload the document to their server. If you reopen the document from their web-based program, it usually works. (This may happen 1 out of 100 attempts). Due to an inasnely annoying bureaucracy, I cannot A) get access to their VBA code to see where the problem is or B) get them to do anything about it. This has been going on for months.

For at time before this error started (I think), I had been using a few macros but not calling them via AutoOpen. It may be a coincidence, but I think it's not, but these errors seemed to have started once I started using AutoOpen.

QUESTIONS

1. Is there any way that AutoOpen would interfere with the correct loading of a document from this sort of process?

2. Any suggestions?

3. And if not, anyone know any good shrinks? Cuz this is driving me crazy...


I'm including the VBA code below, but I'm more concerned with the AutoOpen command itself.

Thank you kindly,

David


Sub AutoOpen()
Dim ResponseQuestion As String
'I added DoEvents here in the vain hope that it would somehow ease the problem--no effect.
DoEvents
Application.Visible = True
Application.WindowState = wdWindowStateMaximize
ActiveDocument.ActiveWindow.WindowState = wdWindowStateMaximize
If (ActiveDocument.ReadOnly = True Or ActiveDocument.ProtectionType <> wdNoProtection) Then
StatusBar = "Macro not operational because document is read only."
Exit Sub
End If
'SearchFunction is just a quick ActiveDocument.Find replacement
Selection.HomeKey Unit:=wdStory
If SearchFunction("CENTER RECEIPT NOTIFICATION LETTER", True, False) Then
'I messed with the SaveInterval to see if not AutoSaving would help things... no luck
Options.SaveInterval = 0
LetterEdit '
Else
Options.SaveInterval = 5
Selection.HomeKey Unit:=wdStory
If SearchFunction("Confirmation of Withdrawal", True, False) Then
Selection.HomeKey Unit:=wdStory
If SearchFunction("Something in the letter.", True, False) Then Withdrawal
End If
Selection.HomeKey Unit:=wdStory
If SearchFunction("NOTICE OF CASE CLOSURE", True, False) Then
Selection.HomeKey Unit:=wdStory
If SearchFunction("Something in the letter.", True, False) Then CaseClosure
End If
End If
EndGame:
CommandBars("NOF").Visible = True
End Sub


/Edit/ Word 2003 /Edit/

[fumei]

Please post full code.

1. SearchFunction is "a quick ActiveDocument.Find replacement". Really? Maybe so, but it is hard to really analyze things without full information.

2. there is a call to "Withdrawl" - with no code to see what that does. Can you be totally sure it does not contribute to the problem?

3. 2. there is a call to "CaseClosure" - with no code to see what that does. Can you be totally sure it does not contribute to the problem?

As it stands, your posted code seem fine to me. Do not see anything obvious, other than the fact you have:

Dim ResponseQuestion As String

but that is it. The variable is never given a value, and is never used. Why declare a variable and never use it?

[MOS MASTER]

Hi, :yes

The Badfilename part is probably caused by the appending of a slash (\) by the code to the filename or perhaps by the upload code truncating the filename. (Try a real short name does it happen then?)

Without the code which you can't get its almost unpossible for us to assist.

Further more Automacros and EventHandlers (Document_Open) can certainly conflict if executed at the same time or some other situation. But again there's to little information.

HTH, :whistle:

[wadiohead]

Please post full code.

1. SearchFunction is "a quick ActiveDocument.Find replacement". Really? Maybe so, but it is hard to really analyze things without full information.




Public Function SearchFunction(SearchString As String, MatchWhole As Boolean, ReplaceBoolean As Boolean) As Boolean
'Search Function
SearchFunction = False
Selection.Find.ClearFormatting
With Selection.Find
.Text = SearchString
.Replacement.Text = ""
.Forward = True
.Wrap = wdFindContinue
.Format = False
.MatchCase = MatchWhole
.MatchWholeWord = MatchWhole
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
If ReplaceBoolean = True Then Selection.Find.Execute Replace:=wdReplaceAll Else Selection.Find.Execute
If Selection.Text = SearchString Then SearchFunction = True
End Function




2. there is a call to "Withdrawl" - with no code to see what that does. Can you be totally sure it does not contribute to the problem?

3. 2. there is a call to "CaseClosure" - with no code to see what that does. Can you be totally sure it does not contribute to the problem?

As it stands, your posted code seem fine to me. Do not see anything obvious, other than the fact you have:

Dim ResponseQuestion As String

but that is it. The variable is never given a value, and is never used. Why declare a variable and never use it?

I'm positive that Withdrawl and CaseClosure don't interfere--I've taken them both out and still gotten the error. Also, they are not called when the error results.

The ResponseQuestion declaration was my fault in copying and pasting--I deleted one section of the code that was added after the errors started happening (and contains some semi-sensitive things for my company). I'm also positive that it is unrelated.

I appreciate your help, Fumei.

[wadiohead]

Sigh. I know. There's ridiculously little to go on. Just a wishful shot in the dark...


The Badfilename part is probably caused by the appending of a slash (\) by the code to the filename or perhaps by the upload code truncating the filename. (Try a real short name does it happen then?)
The file name is always the same "1.htm," so there's not really anything I can do about it. The code renames the file... it's very possible that this is where the error is.

I was definitely worried that AutoOpen could conflict with whatever they're calling on open, but there's not a lot I can do to find out.

I suippose I'll just have to require users to click a button whenever they open a document.

[MOS MASTER]

Hi, :yes

Yes there's little to work on must be frustrating! :banghead:

The only thing I can think of is that the document must be downloaded to the workstation first and maybe this delay is causing the AutoOpen to fire when the document is not fully download (or Initialized to execute)

Another options is that your Third party app is doing something while downloading it to your workspace. (makes more sence) And that is causing problems with your code....

Yes a button could be a option or maybe have it executed on a save command or close. I think it's just a matter of testing things out till you have a working sollution.

But a button would be the savest options cause you have no clue on what that third party app is doing.

HTH, :whistle:

[wadiohead]

Thanks a lot to everybody--I knew it was a shot in the dark attempt. Not surprised, with the complete lack of information I could provide, that answers weren't forthcoming.

Again, thanks for your effort. I'm marking it solved.

-David

[MOS MASTER]

Hi David, :yes

Really sorry we couldn't help you!

See yah next time! :whistle:

[fumei]

Can you walk me through this? I am not getting what is SUPPOSED to happen.

You are going to supply the users with a button...to do what again? There is something nagging at me with this. I don't think this IS solved, and I also believe that it may be possible that it COULD be.

[wadiohead]

Fumei:

It's not so much what the button will do (basically it will run all the code I need), it's what happens when the users run the third-party VBA procedure that's the problem.

But more importantly, and I thank you for pushing this back to my mind, I left out a major detail of my description:

The third party VBA procedure is stored in a template that normally gets attached to the document. However, randomly, the template does not automatically get attached to the document (I think that autoopen is somehow conflicting with this).
To counteract this, I've been attaching the template to the document with

ActiveDocument.AttachedTemplate = "C:\Program Files\Common Files\...Template.dot"


But, when the users try to use the third-party vba procedure to upload the document to the third-party server after I've manually attached the template, the procedure runs but they get a "bad file name" error.

[MOS MASTER]

Hi Guys, :yes

Gerry glad you're so optimistic but the fact is we can't see the add-in code so whe are trully in the dark!

The best thing to avoid the automacro's or eventhandlers is to fire the code manualy.

The problem is that the error seams to come random.

@wadiohead,

Could you explain why you're so sure the templates needs to be attached to that template?

You could btw put some code in to check if the attaching part really took place! (This is not always a succes...so you should check)

Have you checkt on the upload server if that document still attached to the template you think it should be?

Uploading requires a different type of filepath I can presume. (Wouldn't know for sure) but that could be the problem to...

A lot of wild guesses but if your up for it I'll stick with yah just like Gerry! :whistle:

[wadiohead]

I agree that it's probably hopeless. Having this happen at random is definitely the worst part.

The attachment does take place because otherwise the third-party macro wouldn't run. I had actually re-tested that for the millionth time earlier this morning.

I have an earlier version of the third-party code, before they password-protected it. I'd feel uncomfortable posting it here, though, and I don't know what good it could do. But if you want, I'll private mail it to both or either of you.

I'm unsure about whether the file maintains its template-attachment on the server--we can't access it.

[MOS MASTER]

Hi, :yes

Well hopefully the old one isn't that much different then the new one so yes do send it.

Perhaps it will shet some light on this.

Later..:whistle:

[fumei]

Joost, when you get that, pass it on to me. There is something about this that really bugs me.

[MOS MASTER]

Joost, when you get that, pass it on to me. There is something about this that really bugs me.

Done! :yes

[MOS MASTER]

The code isn't that special but it uses relative paths and those can be tricky!

Perhaps a possible source for the error as well.

I mean a line like:
WorkingDoc.SaveAs "C:\DOCUME~1\DGOLDF~1\LOCALS~1\Temp\Contex\1_0\1_0.htm", wdFormatHTML

:whistle:

[fumei]

Ok, I think....and I mean, I just think...it may have to do with WebOptions.OrganizeInFolder.

This is associated with DefaultWebOptions.UseLongFileNames, and the DEFAULT is set to TRUE, long filenames ARE used. There is no code here to check this.

[MOS MASTER]

True, that is a good catch! :yes

Not working to much with that side of Word but the problem could be in there as well. :whistle:

[wadiohead]

That's definitely a good point... As soon as I get the error, I'll try changing the longfilename error. I really, really appreciate your continued help.

David

[MOS MASTER]

As soon as I get the error, I'll try changing the longfilename error.

Hi David, :yes

Do you mean that when you get the error the error stays (if you execute again) until you do something?

So can the behaviour be reproduced at that moment (That would be handle) or is the error always once in a while and just a single error at the time?

:whistle:

[wadiohead]

Every once in a while, under completely arbitrary circumstances, a document will cause this error--and it will keep causing it over and over again unless you recreate the document.

-David

[MOS MASTER]

Every once in a while, under completely arbitrary circumstances, a document will cause this error--and it will keep causing it over and over again unless you recreate the document.

-David

Ok that's great cause this means you will be able to debug it! If you step through your code (F8) you can see at what line the error occurs. (Then debug some more to what the value of the causing variable is.)

So we can test all sort of stuff when the document is in that state so that's a good thing.

If it where at random it would be harder. :yes

[wadiohead]

Finally someone got the error!

The bad file name error is triggered twice; once on the first (non error-trapped) line of

WorkingDoc.SaveAs filename, wdFormatHTML

the other time on:

Set WorkingDoc = Application.Documents(filename)

The problem, it seems, is that the filename is equal to ?\1_0.htm?.

Filename's value is set by the earlier:

filename = entDir & "\" & etype & "_" & eid & ".htm"

And, of course, entDir (which is located in a variable that is supposed to be in the active document) is blank. EntDir is set to ""%userprofile%\Locals~1\Temp\Contex\1_0" when an error doesn't occur.

Several other of their values seem to be blank as well. I don't know if this affects anything or not.


Contexdir = ??
This is set to "%userprofile%\Locals~1\Temp\Contex" when the error doesn't occur.

Username =??
this variable doesn't seem to exist in any documents. Sloppy.

Password =??
This variable also doesn't seem to exist in any documents. Sloppy.

But, I'm going to cross my fingers and hope that adding the entDir variable to the open document will fix the problem.

[MOS MASTER]

This seems like excellent progress to me! :yes

Very good to here you found your sollution.
Btw you can always go back and hardcoding the path like in the old template!

See you in the next challenge! :whistle: