Rename an external file

[Chuck]

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
---

[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.

[John Mishefske]

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
'---------------

[Chuck]

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
---

[Larry Linson]

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
---

[Trevor Best]

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

[Soundneedle]

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.

[Chuck]

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
---