Strange Word2003 bug in Document.FullName

[ChrisGreaves]

This is a heads up and is probably a VERY esoteric bug.
About one time out of three when I run an application of mine (WbWrd compiles Word documents and uploads the HTML to my web site) a line of Word2003 VBA code returns the document Fullname in UPPER-CASE.

Code: Select all

Dim strTrueTargetFullName As String
strTrueTargetFullName = uw.strUNCGetDrive(doc.FullName)

I will be trying to isolate the cause, made a little complicated in that it seems to occur ONLY when I am online, not when I run the compiler in non-upload mode (a sort of "pre-compile" option).
I have searched the web for things like Word2003, Document, Fullname, Upper and so on.
A quick search of Eileen's Lounge starting with Fullname, then narrowing down by Document and Case reveals nothing.
The application has been running happily since 1997, but with modifications from day one and a couple of re-writes.
I have searched my own code for "UCASE" and similar functions, and cannot find a spot where I do anything of the sort. (Which doesn't mean I don't do it, just that I cannot find it)

Two times out of three everything works fine; one time out of three I get upper-case and so I end up creating a directory tree (on my web site) as "TRIPPING" instead of "Tripping", in consequence, images that were previously uploaded to "Tripping" are not found in the documents in "TRIPPING" that try to reference them.

AFAIK no-one else uses this program other than me; so this is not world-altering.

In the first place I am just curious if anyone has ever experienced anything like this.
(continues rambling ...)
It rattles me that right now it seems to occur at random times. I am in these past weeks in a phase of compiling many web pages about Tripping, and some days are fine, other days are Upper-case.

Is this God's way of telling me to upgrade to Win10/Office 2015?

P.S. I will happily make the code available to anyone more masochistic than I

[Jay Freedman]

Chris, I have never seen that sort of problem.

Is the expected format always an upper case first letter and the rest lower case, or would there be other variations (internal caps like FileName, or multiple words that each start with an upper case)?

[ChrisGreaves]

Chris, I have never seen that sort of problem.

Jay, thanks for this feedback; it is almost certainly some weird configuartion (or corruption) in my own system. It's good if it turns out to be "only me" because that suggests I can "do" something about it (see below)

Is the expected format always an upper case first letter and the rest lower case, or would there be other variations (internal caps like FileName, or multiple words that each start with an upper case)?

In general I use a TitleCase for names of folders and files. It is now very rare that I use all Upper-Case – except in those instances where I am testing for equality of file names.
In particular for my web pages I want to use a readable mixture of upper- and lower-case to help a user understand a location. Spoken or read http://www.ChrisGreaves.com/Tripping/Transit" onclick="window.open(this.href);return false; makes sense to me and, I hope, my readers or listeners.
In the case shown in the two attached images the mouse-hover shows that the .FullName is returning a fully-capitalised path, but the screen-shot of the Explorer panes shows Title-cased.
Now it is possible that somewhere I have some code that is sneakily converting a path to upper-case, but the Explorer pane screenshot was taken after/during the interrupted VBA code (and I’m not manipulating facts here) shows that the document does exist and lies in a folder path that is title-cased.
Further, it’s not that a variable of mine such as strTrueTargetFullName has been inadvertently capitalised, for my mouse-hover is showing what the VBA interpreter believes is the path name, before I have assigned a value to a variable.
That the .FullName property returns a capitalized path name is what leads me to believe this is a Microsoft Word bug. I grew up in an age when any computer problem was always the programmer’s fault, so I’ve not ruled out something weird here, but the bug
(1) does appear to be a feature of .FullName
(2) is intermittent (I think about one out of three runs)
I have put in place debugging code to trap when the upper-casing happens and I’m going to see if I can detect a pattern in my use of the application that triggers the bug. For example, perhaps the bug creeps in on the second and subsequent runs of the application in a single Microsoft Word session.
I am also considering rebuilding the application template from scratch, importing code from the output of a VBACleaner run and manually resetting references and so on, just in case some aberration has crept in through repeated editing.
(trudges back to the salt mines .....)

[ChrisGreaves]

I have put in place debugging code to trap ...

And after posting this reply I fired up WbWrd and happily compiled a series of pages.
Noticed a typo, made a correction (to a source page in MSW) and recompiled which triggered the trap.
So at this stage in the game, the first run of the day worked fine, but the second run triggered the bug.
(wanders off to experiment some more ...)
(later) Shuts down MSW, reloads MSW, recompiles page, gets same forced-upper-case error!
Posts this addendum and prepares to reboot ....
(later still) After a shut down and cold reboot, reload MSW, recompile, and get same forced-upper-case error.
Decides to shut down, reboot, reload MSW and try compiling a different set of pages ....
(even later still) Shutdown and recompile pages from a different folder tree. get error/bug.
Decide to go home and lick my wounds and try again tomorrow.
(signed) "You know how I'm feeling" of Toronto

[Jay Freedman]

Just out of curiosity... Can you test the result of doc.FullName directly, rather than the result of uw.strUNCGetDrive(doc.FullName)? If they're in different cases, that points to the uw.strUNCGetDrive code.

[ChrisGreaves]

Just out of curiosity... Can you test the result of doc.FullName directly, rather than the result of uw.strUNCGetDrive(doc.FullName)? If they're in different cases, that points to the uw.strUNCGetDrive code.

Code: Select all

Function strGenerateHTMLFromDocument(doc As Document, os As OptionsStructure) As String
    ' 7314: The line "ActiveDocument.FollowHyperlink strResult" is missing the preamble
    ''' Generate the name of the file in which we store the html code
    Dim strTrueTargetFullName As String
    strTrueTargetFullName = uw.strUNCGetDrive(doc.FullName)
    If InStr(1, doc.FullName, "HOME") > 0 Then
        MsgBox "path is forced ucase " & doc.FullName
        Stop
    Else
    End If
    Dim strTestPath As String
    strTrueTargetFullName = strTrueTargetFullName & strFixPath(uw.struncGetPath(doc.FullName))
    strTestPath = uw.strGetPath(strTrueTargetFullName)
    If uw.strOnly(strTestPath, uw.strcUpperAlpha) = uw.strOnly(strTestPath, uw.strcAlpha) Then
        MsgBox "path is forced ucase " & strTestPath
        Stop
    Else
    End If

Thanks Jay, and yes (new trapping code inserted near head of function to test for forced upper-case "HOME").
It is definitely the doc.Fullname that is returning upper-case, as my original snapshot showing the mouse hovering over the item shows.
I'm going to head home and rebuild this template from exported modules (not rewriting the whole thing from scratch, yet!) and see what tomorrow brings.
That originally a search of the web turned up nothing suggests to me that my system is, somehow, corrupted.

I must too mull over the fact that the first run today worked fine, but all subsequent runs, even after a cold boot, have failed. That is, the application works sometimes!

[Jay Freedman]

Hmm. For a minute or two, I thought it could be that FullName was returning an upper case result for each node that fit within the old DOS 8.3 format. Both TRIPPING and TRANSIT are short enough, but then I realized that GREYHOUND is 9 characters. So much for that theory! Also, index.doc appears in lower case in the same tooltip.

[ChrisGreaves]

... but then I realized that GREYHOUND is 9 characters. ...

Jay don't bash yourself; I'm bashing myself enough for both of us.

Status: This (Sunday) morning at home I made a new folder on my hard drive:-

Untitled.png

All neatly titled-case, new folder, never been seen on my hard drive before and therefore never been seen on my web site before. Regular page (for me) wordy text with some images.
Fired up my WbWrd compiler (with code to trap upper-case in place) and compiled the web page.
Flawless! WbWrd created folders, uploaded images, uploaded HTML text and shelled the page to Firefox and TaDa! there's my web page:-

WbWrdDoubleSlash.png

So far so good.
Next I edited the page (to insert a couple of links, fix a typo, no big deal) and when I recompile it:-

uppercase.png

That's all I've done (in terms of MSWord, WbWrd etc) this session. Friday when I had problems I was at a public library, today at Starbucks, but I don't think those facts are relevant.
It seems as if the first run of the day is OK but that subsequent runs (even after a cold boot, remember) cause doc.FullName to return the path (!) but not the drive of file name or extent as upper-case.
(sulks) (mulls) (cogitates)
I can't believe that Word goes wacky just because I use some borrowed VBA code to test (FTP) the existence of a folder.
So, once I click Submit I am going to FileZilla delete the new folder created ten minutes ago and try re-compiling the web page (with corrected text in place)
Don't go'way ...

[ChrisGreaves]

...So, once I click Submit I am going to FileZilla delete the new folder created ten minutes ago and try re-compiling the web page (with corrected text in place)Don't go'way ...

(In Agony)
FileZilla, deleted the folder from my web site. Also deleted the HTML file from my hard disk. Deleting the html from my hard disk forces WbWrd to recompile the page (it recompiles if the DOC is newer than the HTML, but I didn't want to edit/save the text just for the sake of doing it, today).
Deleting the folder from the web forces WbWrd to check for the existence of a folder and create it if necessary.

So in theory ten minutes ago I was back to where I was thirty minutes ago.
I recompiled the page, went flawlessly.
I made a small change (deleted the word "Sunday") and saved the file.
The DOC now being later than the existing HTML will force a compile and upload.
WbWrd trapped the path all in upper-case.

(Sulks, Mulls, Cogitates, all in title-case).

I think the time has come for me to do four things:
(0) See what happens if I pass a string parameter strDocFullname to my function instead of generating it in-function from doc.FullName
(1) Build a stripped-down version of everything in an attempt to force the bug/problem with a minimum of code
(2) Repeat today's experiments Tuesday (I'm out of town Monday)
(3) Seriously consider rebuilding Win7HP and installing Office 2010 if that is the latest.
But I sure am going to miss my toolbars ...

[ChrisGreaves]

(0) See what happens if I pass a string parameter strDocFullname to my function instead of generating it in-function from doc.FullName

1:25 PM 08/11/2015 Same deal. 1st compile OK; 2nd compile forced upper-case
1:26 PM 08/11/2015 3rd compile forced upper-case
1:37 PM 08/11/2015 added debug.print all the way back up the calling sequence to the user macro. Upper-case path is reported at every stage.

Closed my (opened for editing) WbWrd compiler.
I am left with a new "Document1" and an unsaved document on my desktop.
In the debug window I see:-

Code: Select all

?activedocument.FullName
W:\WHIMSICAL\COOKING\SAVOYCABBAGE\index.doc

with the result of an uppercase document.

1:39 PM 08/11/2015 I close (and save) the document, re-open it immediately (File, 1) and

Code: Select all

?activedocument.FullName
W:\Whimsical\Cooking\SavoyCabbage\index.doc

Magically the path is now reported in proper-case, "proper" in the MSWord sense and proper in the sense that it reports the literal characters I have used as names of my folders.

I reopen WbWrd (so I can intervene at my STOP statement) and recompile the document; works perfectly - compiles, uploads, shells to Browser showing correct path as the URL.

Wanders off to cogitate a bit more.
Considers (0.5) I wonder what happens if I write a new macro to replace "DoActiveDocument" with a File,Save followed by my new macro "BrowseTo, and Compile a Document".
It seems as if closing and then re-opening a document fixes whatever it is that is forcing upper-case to be reported by Document.FullName.

[rgrosz78]

This is a heads up and is probably a VERY esoteric bug.
About one time out of three when I run an application of mine (WbWrd compiles Word documents and uploads the HTML to my web site) a line of Word2003 VBA code returns the document Fullname in UPPER-CASE.

...

P.S. I will happily make the code available to anyone more masochistic than I

Chris, I will take a look with my Word 2003 - send me your code.

[ChrisGreaves]

It seems as if closing and then re-opening a document fixes whatever it is that is forcing upper-case to be reported by Document.FullName.

Another day, another dolour
This is an almost pointless exercise, which is why it probably appeals to me greatly.
I had a vague idea that the bug was related to "a new day" since my first run always worked, but subsequent runs, even after a cold boot, failed.
So I waited a day. Wednesday (today) I recompile my changed document, works perfectly - compile, upload, shell to Browser.
2nd run (after a minor change involving only the insertion of a carriage-return) failed.
Huh?
Maybe the problem is IN the document, so I quit MSW, renamed the folder, created a new folder, created a new document "index.doc" with text "this is a test", no graphics, no hyperlinks, no linked images ...
... works perfectly - compile, upload, shell to Browser.
Of course, that's the FIRST run of this (new) document today.
Made a small change (appended "still!").
2nd run failed (Forced Upper Case, which I am struggling NOT to abbreviate ...)

Now I'm going to try creating a new folder tree to see if the path itself causes a problem ...
(minutes later)
Nope. Created a new set of folders on my "web" drive: W:\One\Two\Three and a new document W:\One\Two\Three\index.doc
Smidgen of text, 1st compile works fine.
Minor text edit, save, recompile - bombs again with Forced Upper Case.
So it appears NOT to be related to my SavoyCabbage essay document, nor to the pre-exisitng path W:\Whimsical\Cooking\SavoyCabbage

My bet is that If I trudged up here tomorrow, the FIRST recompile would work and the second wouldn't, so let me step into my time-machine and advance the date on this laptop, cold-boot and ...

... a day flashes by in mere minutes. I contemplate changing my signature.
So here it is, Thursday 13th August 2015.
I make a small change to my new document (W:\One\Two\Three\index.doc), save it, recompile. Perfect. Compile, Upload and Shell to browser.
This is, remember, the first recompile of this document this faked day
I make another small change to my new document (W:\One\Two\Three\index.doc), save it, recompile. FAILS. Because (???) this is the second compilation of this document this day.

At this point I feel that I have a bug in Word2003 that is triggered only after the first use of the day.

[ChrisGreaves]

Chris, I will take a look with my Word 2003 - send me your code.

Rick, I don't normally associate with gluttons for punishment (grin) but in your case I might make an exception.
Give me another day or two to eliminate all the (to me) obvious causes and produce a stripped-down reproducible problem, then I'll ship you the code.

[PJ_in_FL]

Chris,

I saw you state the document was saved when you ran through the code, but does Word also see the state of the document as saved or could it still be in an "edit" state (i.e. "Document.Saved = False") when the error occurs?

Didn't make a difference in my testing (Word 2007 -- still putting off the IT-forced Office 365 install ), but thought I'd grasp at a straw or two in this story.

[ChrisGreaves]

... (i.e. "Document.Saved = False") when the error occurs?

PJ Thanks for the comments/suggestions. ALL straws are welcome right now, to this drowning man.
I have not tested doc.Saved, but will do that now.

In my general running, I open and edit the document, then save and close it.
I wrote WbWrd in part so that I could update web pages (well, their DOCument source) and just leave the document there until the next time I decided to update the folder tree. (Imagine I'm working on some task, and a thought pops into my head about a different task; it takes less than a minute to open the second task document, edit and close it, knowing that it will be swept up on the next compilation)

That means, in general, that WbWrd is given a document and then follows all hyperlinks to other documents, opening them (therefore I believe .Saved will be TRUE), compiling, uploading and then closing them.
The more so nowadays since I tend to sit at home and make edits, then ShutDown, walk to the WiFi place, cold boot, open the doc and recompile the tree.

This past few days I am editing and compiling on-the-fly, so your suggestion to test .Saved is valid, and I will incorporate it into my debugging code.

Thanks.
Keep those straws floating this way ...

[ChrisGreaves]

At this point I feel that I have a bug in Word2003 that is triggered only after the first use of the day.

(later the same day) I revisited all my old haunts - the one\two\three exercise, savoy cabbage, changing the date etc.
I am now back on Wednesday August 12th.
My next sally is/was to experiment with a new macro, one which would allow me to browse-and-open the document to compile it, rather than compile-the-active-document.
Here is my older macro, used for years ...

Code: Select all

Sub DoActiveDocument()
    Debug.Print "DoActiveDocument " & ActiveDocument.FullName
    If Documents.Count > 0 Then
        Call DoASingleDocument(ActiveDocument)
    Else
        Call amlog(ThisDocument, "You need to have a document open!" & vbCrLf & "Or try running DoLatestDocument.", True, True)
    End If
End Sub

Here is my new (today!) document:

Code: Select all

Sub DoBrowsedDocument()
    Dim strFilter As String
    strFilter = "Word DOCUMENT Files (*.doc)" + Chr$(0) + "*.doc" + Chr$(0) + "All Files (*.*)" + Chr$(0) + "*.*" + Chr$(0)
    Dim strBrowsedDoc As String
    strBrowsedDoc = UW.Browsers.strBrowseFile2("Please browse to a compilable document", strFilter, "W:\")
    If Len(strBrowsedDoc) > 0 Then
        Dim doc As Document
        Set doc = Documents.Open(strBrowsedDoc)
        Debug.Print "DoActiveDocument " & ActiveDocument.FullName
        If Documents.Count > 0 Then
            Call DoASingleDocument(ActiveDocument)
        Else
            Call amlog(ThisDocument, "You need to have a document open!" & vbCrLf & "Or try running DoLatestDocument.", True, True)
        End If
    Else
    End If
End Sub

Both macros call the function "DoASingleDocument" and ought to trigger the problem.
The new macro does NOT trigger the problem, and I will be making several runs on different pages after this posting.
PJ might be circling the truth here; the trigger might be related to the fact that the document is open, even though it is saved (by me with a File, Save) and even though my debugging code tells me .Saved=TRUE.

Right now it seems as if passing an OPEN document to the function can trigger the problem, but allowing VBE to open the document before passing does NOT trigger the bug.
We need a new smiley for once all the hair has been 'ed out.

(half an hour later) my new macro "DoBrowsedDocument" seems to bypass the problem. I have recompiled a variety of folder trees (that is, hyperlinked sets of documents) and not one of them has failed with a Forced Upper Case path.

[Rudi]

Glad to see that progress is being made (though it is slow) and a pattern seems to be emerging.
Sorry I cannot be of much help on this one!

[ChrisGreaves]

Sorry I cannot be of much help on this one!

Well, Rudi, you never know; that might be a good thing for both of us (Just Kidding!).

FUC073.png

To All:-
The mystery deepens. While preparing a package/zip file for Rick I had reason to recreate a simple web site with three documents in the leaf folder.
Here I am (screenshot above) after reloading MSWord, not doing anything of my own application work, just simple create-document, type-in-text, make a hyperlink, save-and-close stuff.
To my surprise the File menu in MSW shows the second and third documents with FUC paths.
Now, these documents have not been touched by my compiler, and these three documents are prepared as simply as would students in a basic MSW course ("This morning we are going to create hyperlinked documents ...").
So now I suspect that the FUC bug is not a facet of WbWrd, but is related to my installation, possibly corrupt.
My current feelings are attached as a MSW document.

[ChrisGreaves]

Chris, I will take a look with my Word 2003 - send me your code.

http://www.chrisgreaves.com/Downloads/20150815_1346.zip" onclick="window.open(this.href);return false;
Rick, this is a stripped-down version that manifests the bug on my system, with documentation.
I am primarily interested in knowing whether you are able to make the bug occur; tracking down the cause is my job

To You All: Rick is, after me, North America's expert on the application MRUse, so he is well qualified to treat this.
Rick is also one of the top motivational coaches that have ever entered my life.

On top of that he has mentioned two friends who I will deviously co-opt into my circle, which is why i am buttering him up right now, but don't tell hom that, OK?

Seriously: I still think that this is an Office2003 bug because IMHO the Document.FulllName property ought not return an upper-case rendition of the Path of an active document when that path is clearly in upper-and-lower case.

[ChrisGreaves]

This is a heads up and is probably a VERY esoteric bug.

I have been trying to isolate this bug over the past week or so.
My latest documentation is at http://www.chrisgreaves.com/Downloads/20150821_1110.zip" onclick="window.open(this.href);return false;, although I'm not expecting a critical review.
As of Today, Friday, I *think* I have eliminated the VBA code in my addins as the trigger.
Unless I can come up with any other test I will assume that it is my laptop configuration that is at fault.
This will mean
(1) Making a system image of the assumed-corrupt system in case I come up with a better trapping idea in the future
(2) Making a bare-bones clean installation of Win7HP/Office2003 from CDs (I can't go back to my system image of some months ago because it isn't squeaky-clean, and I'd want no added freeware utilities in place for this test)
(3) Testing and adding in customized components on a daily basis, making system images as I go.
The nice man at modcomcomputers sold me a 1TB USB drive earlier this week. I'll go back and buy more if I have to maintain a tribe of system images ... I will NOT be beaten by a chunk of metal and plastic!

(signed) "Don Quixote MkII" of Toronto