Unique Backup Filename, Not

  • Thread starter Thread starter AA
  • Start date Start date
A

AA

I use Word's automatic backup feature, (Options>Save>
AlwaysCreateBackupCopy), which has saved me grief on more
than one occasion.

Lately I've been editing two documents at the same time,
named something like "Brown.Coverletter.May5.doc" and
"Brown.Summary.May5.doc". The problem is that the backup
file for each document is the same: "Backup of Brown.wbk",
because apparently all backup copies are named "Backup of
<whatever precedes the first period in the filename>.wbk".

Any clever VBA script to modify this behavior so that more
of the original filename is incorporated in the backup
filename? Or some other way to get unique backup copies in
this situation other than changing my file naming protocol?

TIA,

Andy
 
I think your file-naming protocol has to go. There's no obvious VBA way to
do it: Word's function for creating the backup filename is not exposed.
Changing your file naming will be a one-off nuisance, while any other
solution will be a permanent PIB. Just replace the periods with underscores
or spaces and your problem's gone.

Bear in mind, your problem isn't just with documents open simultaneously.
Your back-ups are getting overwritten anyway. You'll have only one back-up
file for *all* your Brown letters, containing whichever one you saved most
recently.
 
You might find a macro to save in two separate locations useful - see
http://www.gmayor.com/automatically_backup.htm
Click to expand...

Thanks Graham, I looked at this before, but it doesn't do what I want.

I need to save myself from flying fingers and momentary idiocy,
accidentally hitting Ctrl-S when the last thing I want is to save my
current file, overwriting the copy I really want. Word's automatic
backup feature works just fine for this.

I'm wondering if I could adapt the macro to do exactly what I want
though. It depends if there is a VBA command to copy a file.

Sub CallMyBackUpFileWhatIWantTo()
Dim strFileA, strFileB
strFileA = ActiveDocument.Name
strFileB = strFileA & ".baq"
<is there a VBA command to copy strFileA to StrFilB?
<Doing it in the current directory would be fine.
<I could do that first, backing up the unsaved file,
<then the next step would be to actually
<save the current file:
ActiveDocument.Save
End Sub

An added benefit would be that my backup filename would look like
the original filename, and would sort better in Explorer.

What do you think?


Andy
 
I think your file-naming protocol has to go. Changing your file
naming will be a one-off nuisance, while any other solution will
be a permanent PIB. Just replace the periods with underscores or
spaces and your problem's gone.
Click to expand...

That would work, although I sometimes do command line stuff on all the
"Brown" documents, eg "copy Brown.*.*.* A:*.*.*.*.2003", or "dir
c:\*.summary.*/s". Not the most useful examples, but you get the idea.
Plus then I'd have a mixed batch of file-naming protocols unless I
went back and changed all my old files.

Bear in mind, your problem isn't just with documents open
simultaneously. Your back-ups are getting overwritten anyway.
Click to expand...

That's ok, I'm diligent about backing up my work when I'm finished
each day anyway. When I need to keep iterations while I'm working, I
just right click and drag, and make a "Copy (n) of..".

You'll have only one back-up file for *all* your Brown letters,
containing whichever one you saved most recently.
Click to expand...

That would be ok too, as long as I have one for *each* Brown document,
just while I'm working. I need to save myself from flying fingers and
momentary idiocy, accidentally hitting Ctrl-S when the last thing I
want is to save my current file, overwriting the copy I really want.
Word's automatic backup feature works just fine for this.

There's no obvious VBA way to do it: Word's function for creating
the backup filename is not exposed.
Click to expand...

See my post to Graham, maybe there's a way to do what I want.
 
Graham,

Here's what I figured out, seems to work ok:

Sub xBackupAndSave()
Dim strFileA, strFileB, fs
strFileA = ActiveDocument.Name
strFileB = strFileA & ".baq"
Set fs = CreateObject("Scripting.FileSystemObject")
fs.CopyFile strFileA, strFileB
ActiveDocument.Save
End Sub

It's now assigned to Ctrl-S. I still have Always Create Backup Copy
checked until I see if I run into problems.

Andy
 
You don't need the FileSystemObject for this. VBA's built-in FileCopy method
does the same thing.
 
You don't need the FileSystemObject for this. VBA's built-in FileCopy method
does the same thing.
Click to expand...

I tried FileCopy, but it doesn't work on an open file.

I don't even know what FileSystemObject is, but CopyFile wouldn't work without
it. The line of code defining fs,

Set fs = CreateObject("Scripting.FileSystemObject")

was something I copied from a help screen just to see if it would work,
typical of my way of stumbling around VBA using trial and error. Most of the
help screens make very little sense to me, I don't understand much of the
basic terminology.
 
'Scripting' refers to the Microsoft Scripting Runtime object. You're
currently using late binding to create a reference to it. You could use
early binding by adding Microsoft Scripting to the project's references
(VBA - Tools > References), then instantiate the object using:

Dim fs as Scripting.FileSystemObject

set fs = New Scripting.FileSystemObject

A lot of experienced programmers have vehement objections to using this
object (check the VB forums for some seriously vitriolic discussions) mostly
on the grounds that it's unreliable, insecure, and unnecessary. Also, users
can disable it completely through the browser Internet options dialog.
 
'Scripting' refers to the Microsoft Scripting Runtime object. You're
currently using late binding to create a reference to it. You could use
early binding by adding Microsoft Scripting to the project's references
(VBA - Tools > References), then instantiate the object using:

Dim fs as Scripting.FileSystemObject

set fs = New Scripting.FileSystemObject
Click to expand...


Ok, now I have:

Sub xBackupAndSave()
Dim strFileA, strFileB
Dim fs As Scripting.FileSystemObject
Set fs = New Scripting.FileSystemObject
strFileA = ActiveDocument.Name
strFileB = strFileA & ".baq"
fs.CopyFile strFileA, strFileB
ActiveDocument.Save
End Sub

Which works most of the time once I enabled Microsoft Scripting Runtime.

All I know is that CopyFile requires a FileSystemObject (whatever that
is), and that now I have one - apparently a better one than I had before.

With either the original macro or this revision, once in a while I
get a "file not found" error message, even though the macro is
defining strFileA and strFileB ok according to the Locals window as I
step through it.

I'm more accustomed to understanding what I'm doing, it's a bit
unsettling just blundering around.

It is nice however to have backup files named the same as the original
with just a .baq extension added. Makes the file listing in Explorer
more readable, and I don't overwrite my backup file unintentionally.

Thanks for your help.

Andy
 
Hi Andy,

Here's a little background about the FileSystemObject and what it's
doing...

When you set a reference to the Scripting Runtime library in the
References dialog, you're telling VBA that you want to use code in the
file C:\Windows\System32\scrrun.dll. One of the sections of that code
supplies the properties and methods that belong to the
FileSystemObject, which knows how to manipulate drives, folders, and
files. The documentation for that object is available from the VBA
Help or online at
http://msdn.microsoft.com/library/en-us/script56/html/jsfsotutor.asp.
CopyFile is one of the methods that belong to FileSystemObject

When you used the CreateObject method before, you were getting the
same FileSystemObject, but you were relying on the registry to find
the scrrun.dll file at run-time instead of linking into it through a
reference. There are advantages to both ways; the main advantage of
using a reference is that you can get the "IntelliSense" popups that
show the available methods.

To figure out why you sometimes get an error, try to analyze what's
the same about documents that cause the error, and how they're
different from ones that don't. For example, the CopyFile method goes
out to the disk looking for a file whose name is the string contained
in strFileA. If that file doesn't exist in the given location --
either it hasn't been created yet or it has been moved or deleted,
regardless of whether it exists in Word's memory area -- then "file
not found" is exactly correct.
 
Thanks for the explanation Jay! Things are very slowly becoming
clearer.
To figure out why you sometimes get an error, try to analyze what's
the same about documents that cause the error, and how they're
different from ones that don't. For example, the CopyFile method goes
out to the disk looking for a file whose name is the string contained
in strFileA. If that file doesn't exist in the given location --
either it hasn't been created yet or it has been moved or deleted,
regardless of whether it exists in Word's memory area -- then "file
not found" is exactly correct.
Click to expand...


It will happen with the same file. The macro will work fine several,
or even many times and then suddenly I'll get the error. If I use the
conventional Save dialog, after that the macro will start working ok
again. The one thing I have noticed, although it doesn't always happen
then, is that I am seeing unhidden temporary files that are named
differently than the usual hidden ones (~WRL3502.tmp as opposed to the
hidden file ~$ller.4530.Summary.doc). I'll reboot and see if it
continues. It's surprising how often restarting fixes odd behavior.

When my work situation eases up a bit, I'm going to want a *real* VBA
book to read, one with general principles but also with specific Word
and Excel commands. I'll ask for recommendations when the time comes.

Thanks,

Andy
 
To figure out why you sometimes get an error, try to analyze what's
the same about documents that cause the error, and how they're
different from ones that don't. For example, the CopyFile method goes
out to the disk looking for a file whose name is the string contained
in strFileA. If that file doesn't exist in the given location --
either it hasn't been created yet or it has been moved or deleted,
regardless of whether it exists in Word's memory area -- then "file
not found" is exactly correct.
Click to expand...

It seems as if the macro always works if I open Word by clicking on the
file in an open folder, and also I think if I load the file thru Word's
Open dialog. Loading the file through the File Menu List or Work Menu,
or a command line (I have a shortcut that starts Word with the Most
Recently Used File) seems to render the macro useless, giving me the
File Not Found error message, even though the String Value is being
properly calculated. Do I need some kind of path information?
 
You need to do more work with folders and names. The ActiveDocument's name
is always unqualified (ie contains no path information). The Document's
FullName is the fully-qualified name.

Using the name alone will work only if the current folder (as FSO sees it)
is in fact the folder containing the document. If you opened the document by
using File > Open and browsed to the folder containing it, this will be the
case; but if you opened the document some other way (from a reference, from
the recent files list, from VBA, etc) then it mightn't be.
 
You need to do more work with folders and names. The ActiveDocument's name
is always unqualified (ie contains no path information). The Document's
FullName is the fully-qualified name.
Click to expand...

I changed:
strFileA = ActiveDocument.Name

to:
strFileA = ActiveDocument.FullName

and that seems to have done the trick. In the VBA Local window, strFileA
and strFileB expand to full path&filename.

Thanks!!!
 
Back
Top