microsoft.public.word.vba.general

Thank you, Jean-Guy.

I'm afraid I don't understand the term "deprecated" in the context of VB
programming, or the last five lines of your note. You can see how little I
know.

But my macro is quite simple in that all it really does is open a mail merge
template file and perform a mail merge output with it. I've done a poor job
of explaining it. Here it is:

1. From a dlg box, you select the type of merge. eg: "Invoice PDF"; "Invoice
Printer"; "Bank Deposit";

2. That determines which mail merge template is opened (because each of the
above selection is also a document name);

3. That document is opened:

WordBasic.FileOpen Name:="c:\windows\winword\merge\" + FilName$,
ReadOnly:=0, PasswordDoc:="", PasswordDot:=""

4. No matter which of the above merge templates is selected, it always uses
the same 'Data File'. Let's call it "Export.txt". This is what my database
exports. Always to the same location so the Word merge template can find it;

5. The macro triggers the mail merge:

WordBasic.WW2_PrintMergeToDoc Suppression:=0

That's all.

The first time it runs, it's fine. The merge output document is perfect. But
then I run it again... each time I begin with the export from the database to
create a new Export.txt. But now the merge output document is the same as the
first merge. IOW, it's not using the newly created Export.txt.

If I quit Word, restart it, then re-run the process it's fine. It uses the
newest Export.txt.

It's as though Word won't let go of Export.txt being used as the Data File,
or the merge template, until I quit the program. (I have noticed file names
beginning with "~". These temp files do not disappear after the macro closes
the relevant document)

The line:

FirstWin$ = WordBasic.[WindowName$]()

isn't terribly important. It's been so long I barely remember it's purpose.
But I believe it was to make sure that the merge template was closed. It
screws up if I try running this macro with the merge template already open.
So I later use:

WordBasic.Activate FirstWin$
WordBasic.FileClose

Best regards,
John

"Jean-Guy Marcil" wrote:

> "John Ciccone" wrote:
>
> > Thank you, Guy.
> >
> > There's not much to the code... once the database app exports to a delimited
> > file, it sends a command to Word via DDE to run a Macro.
> >
> > This macro performs a mail merge using the aforementioned exported file as
> > the Data source. Essentially as follows:
> >
> > ================
> >
> > Dim FirstWin$
> > Starter:
> > On Error GoTo Trouble
> >
> > PastDlg:
> > WordBasic.FileOpen Name:="c:\windows\winword\merge\Bank Deposit Form.doc",
> > ReadOnly:=0, PasswordDoc:="", PasswordDot:=""
> > WordBasic.ViewDraft 1
> > FirstWin$ = WordBasic.[WindowName$]() 'get the title of the current
> > window
> >
> > WordBasic.WW2_PrintMergeToDoc Suppression:=0
> >
> > ================
> >
> > It goes through the motions and does the mail merge to new document, but
> > after it's done it once, it keeps using the same data somehow... even though
> > the data doc has been overwritten with newly exported files.
> >
> > If I quit Word, and re-run it, it correctly uses the most recently exported
> > file.
>
> I am not sure I undesrstand all that is going on, but from looking at your
> code I notice two things: It is using WordBasic commands which are deprecated
> for the most part (We only use some of them becasue they often offer a
> shortcut or a way of doing things that the newer object model does not
> offer), and I do not see the link between the Access-created file and the
> merge operation, other than the line:
> FirstWin$ = WordBasic.[WindowName$]()
> Relying on "current" windows or documents when automating Word is usually
> not a good idea.
>
> I would declare actual objects and made sure that I use those objects in the
> code.
> Here, I would declare two document objects:
> Dim docSource As Document
> Dim docMerge As Document
> Then I would set the two objects and use them in the code to make sure I
> was using the right documents.


Thank you, Jean