By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,095 Members | 1,061 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,095 IT Pros & Developers. It's quick & easy.

Rename an external file

P: n/a
Problem: to rename a file sent to a PDF writer

A macro opens a report in print mode
the printer is a pdf writer
The report name is: "Directory.pdf"
The desired name is: "Directory " & (format(Date(),"yymmdd")) & ",pdf"
So that the file name becomes: "Directory 050126.pdf"

I have tried the NAME {oldfilename} AS {newfilename} as an event procedure In:
On Close and On Deactivate.

Both produce errors because the program is trying to rename the file before the
file print process is complete and therefore the file does not exist at the
time it is trying to be renamed.

All suggestions will be gratefully received.

Chuck
---

Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Rog
I haven't tried this but you could loop until the pdf file exists,
something like:

do until Len(Dir("c:\...\directory.pdf") <> 0
loop

but give it a maximum number of loops in case something goes wrong and
the file cannot be created.

Nov 13 '05 #2

P: n/a
Rog wrote:
I haven't tried this but you could loop until the pdf file exists,
something like:

do until Len(Dir("c:\...\directory.pdf") <> 0
loop

but give it a maximum number of loops in case something goes wrong and
the file cannot be created.

And throw in a DoEvents statement in that loop so that Access (rather,
VBA) yields to the CPU so that the OS so that it can actually do the
file writes.

--
'---------------
'John Mishefske
'---------------
Nov 13 '05 #3

P: n/a
On Thu, 27 Jan 2005 23:39:15 -0600, John Mishefske <mi************@JUNKtds.net>
wrote:
Rog wrote:
I haven't tried this but you could loop until the pdf file exists,
something like:

do until Len(Dir("c:\...\directory.pdf") <> 0
loop

but give it a maximum number of loops in case something goes wrong and
the file cannot be created.

And throw in a DoEvents statement in that loop so that Access (rather,
VBA) yields to the CPU so that the OS so that it can actually do the
file writes.


Thanks Rog and John.

I did the 'do until loop' with out a counter to prevent endless looping in the
OnClose event of the report.
The pdf file is going to exist - eventually.
Apparently, as soon as the report starts to print to the pdf printer, the
report closes. There's no close command in the macro that opens the report.
And the private sub stops even thou it has not found the pdf file.

I'm not a code writer and do not understand the DoEvents function. After
looking at the help file and the example it would appear that the DoEvents is
never going to happen anyhow because the report with the code will be closed.

A not very clean work around is to open then close an unrelated report with the
code, with out the loop, after the pdf file has been saved.

Code:
Private Sub Report_Close()
Do Until Len(Dir("e:\MyData\Directory.pdf")) <> 0
Name "e:\MyData\ Directory.pdf" As "e:\MyData\ Directory " &
(Format(Date, "yymmdd" & ".pdf"))
Loop
End Sub

Chuck
---

Nov 13 '05 #4

P: n/a
DoEvents gives up control to the Windows to allow other events ("things") to
happen. I don't know what your expectation was, but the purpose of that
suggestion was to allow the user to take any kind of manual action to
interrupt the running of the code if you happened to make a small mistake
that put it into a never-ending loop.

Yep, Windows _IS_ supposed to have pre-emptive multitasking, but -- trust
us, you nee the DoEvents!

Larry Linson
Microsoft Access MVP

"Chuck" <li*****@schoollink.net> wrote in message
news:3m********************************@4ax.com...
On Thu, 27 Jan 2005 23:39:15 -0600, John Mishefske <mi************@JUNKtds.net> wrote:
Rog wrote:
I haven't tried this but you could loop until the pdf file exists,
something like:

do until Len(Dir("c:\...\directory.pdf") <> 0
loop

but give it a maximum number of loops in case something goes wrong and
the file cannot be created.
And throw in a DoEvents statement in that loop so that Access (rather,
VBA) yields to the CPU so that the OS so that it can actually do the
file writes.


Thanks Rog and John.

I did the 'do until loop' with out a counter to prevent endless looping in

the OnClose event of the report.
The pdf file is going to exist - eventually.
Apparently, as soon as the report starts to print to the pdf printer, the
report closes. There's no close command in the macro that opens the report. And the private sub stops even thou it has not found the pdf file.

I'm not a code writer and do not understand the DoEvents function. After
looking at the help file and the example it would appear that the DoEvents is never going to happen anyhow because the report with the code will be closed.
A not very clean work around is to open then close an unrelated report with the code, with out the loop, after the pdf file has been saved.

Code:
Private Sub Report_Close()
Do Until Len(Dir("e:\MyData\Directory.pdf")) <> 0
Name "e:\MyData\ Directory.pdf" As "e:\MyData\ Directory " &
(Format(Date, "yymmdd" & ".pdf"))
Loop
End Sub

Chuck
---

Nov 13 '05 #5

P: n/a
Larry Linson wrote:
DoEvents gives up control to the Windows to allow other events ("things") to
happen. I don't know what your expectation was, but the purpose of that
suggestion was to allow the user to take any kind of manual action to
interrupt the running of the code if you happened to make a small mistake
that put it into a never-ending loop.

Yep, Windows _IS_ supposed to have pre-emptive multitasking, but -- trust
us, you nee the DoEvents!


Even if Windows' multitasking was as good as Linux's, it would still be
a good idea to use it. This would allow your own application to process
messages, e.g. using a cancel button within a loop, without DoEvents you
could never hit that button.

--
This sig left intentionally blank
Nov 13 '05 #6

P: n/a
Rog, would looping like this work if a file is created as soon as PDF
writer starts spittting it out? IE, the file starts to exist before
it's been completely written.

Nov 13 '05 #7

P: n/a
On Sun, 30 Jan 2005 13:02:42 +0000, Trevor Best <no****@besty.org.uk> wrote:
Larry Linson wrote:
DoEvents gives up control to the Windows to allow other events ("things") to
happen. I don't know what your expectation was, but the purpose of that
suggestion was to allow the user to take any kind of manual action to
interrupt the running of the code if you happened to make a small mistake
that put it into a never-ending loop.

Yep, Windows _IS_ supposed to have pre-emptive multitasking, but -- trust
us, you nee the DoEvents!


Even if Windows' multitasking was as good as Linux's, it would still be
a good idea to use it. This would allow your own application to process
messages, e.g. using a cancel button within a loop, without DoEvents you
could never hit that button.


Thanks to all who tried to help. Unfortunately I don't undrestand what you all
are telling me. I have put the event procedure in an unrelated report that is
manually opened and closed after the pdf file is printer. Awkward, but
liveable.

Chuck
---

Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.