Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

changing to a printer and changing the default tray in Word 2003

Status
Not open for further replies.

JudyL

Instructor
Feb 21, 2001
148
US
I have a macro that changes the active printer and then runs a mailmerge. When the mailmerge is done, it runs a MailmergeAfterMerge event that unlinks the fields in the resulting document. I also want the event code to change the default tray for the printer. When I run the merge, it crashes when it gets to the code to change the default tray. If I don’t have that code to change the paper tray, it runs fine. If I run another macro to change the paper tray, that code runs just fine.

I think this is a timing issue because it may be trying to jump into the code before it is ready to execute it though I have moved the line around with no good result. Isn’t there a way to slow down the speed of the macro?

The code I use to change the printer in the starting macro is:
Application.WordBasic.fileprintsetup printer:= "\\and the name of print queue", DoNotSetAsSysDefault:=1
I use the above code so the default printer is not changed.

Then in the MailMergeAftermerge event code is:
Options.DefaultTray = "drawer 2(left deck)
 
hi judy,

Re:
When the mailmerge is done, it runs a MailmergeAfterMerge event that unlinks the fields in the resulting document.
There should be no need to do this. All mergefields are unlinked during the merge. The only fields that might not be are those containing other types of fields, all of which can be unlinked by embedding them inside either a QUOTE field or an IF field.

Re:
I also want the event code to change the default tray for the printer.
AFAIK, if you configure your mailmerge main document so that it points to the correct printer tray, this shouldn't be necessary.


Cheers
[MS MVP - Word]
 
To answer your comments:
Quote:
When the mailmerge is done, it runs a MailmergeAfterMerge event that unlinks the fields in the resulting document.
There should be no need to do this. All mergefields are unlinked during the merge. The only fields that might not be are those containing other types of fields, all of which can be unlinked by embedding them inside either a QUOTE field or an IF field.

My mailmerge is actaully doing some document assembly so the main document is then merging in other merge docuemnts based on the value of the fields. Those in turn merge in other documents. Because of this, we end up with fields. Those are the ones we need to unlink.

In answer to the printer tray question, because of the very elaborate document assembly process that is going on, it has to be done this way. Trust me on this one. We have lots of section breaks going on here, which can wreck havoc if not done the way I am doing it.

I think we are just going to require that the job be run only by certain machines and make sure that the default tray for that print queue is set to desired tray that we want. That does work.

Thanks for you reply.
 
Hi Judy,

Re:
My mailmerge is actaully doing some document assembly so the main document is then merging in other merge docuemnts based on the value of the fields. Those in turn merge in other documents. Because of this, we end up with fields. Those are the ones we need to unlink.
Thats is exactly the kind of situation to which embedding your fields inside either a QUOTE field or an IF field would apply an uatomatic unlinking.

Re:
In answer to the printer tray question, because of the very elaborate document assembly process that is going on, it has to be done this way.
No, it doesn't. Have you actually tried setting the tray options in your mailmerge main document (before executing the merge)? You could also use a PRINT field, for example, to send instructions to the printer as to which tray to print from, whether to duplex, and so on (naturally, you wouldn't want to unlink these fields, though...). With PRINT fields, you can change the print options at any point in the document.

Getting back to your original question:
Isn't there a way to slow down the speed of the macro?
You could insert a delay into the code with code like:
Code:
Dim SngTime As Single
SngTime = Timer
While Timer < SngTime + 1
  DoEvents
Wend
In the above, the '1' introduces as 1-second delay, whilst allowing other system processes to continue.


Cheers
[MS MVP - Word]
 
Thanks for the reply. I will try your suggestions.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top