468,268 Members | 1,699 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,268 developers. It's quick & easy.

How can I open a Report modally?

I have a report that prints a single record. Normally it's enter
one record, then print it.
This works great.

New requirement: Each record needs to be printed to an individual
..pdf file from any of several workstations. These will be digitally
signed. No problem except that I have been asked to batch all
existing records.

Wrote a code loop that calls the report for each record. Works
great if the acprintnormal option is used, I get a hard copy for
each record.

But: the .pdf driver name varies from machine to machine, so I cant
set it as "Specific printer" in setup.
I cannot force the users to make the .pdf driver their default
printer.

If I open the form in acreportpreview mode, the report opens on the
first record, and I can select the .pdf driver from the menu,
assign the filename, and save the printout, but the loop keeps
going through all the records, not opening them.

If I were looping through a form, opening it in modal view would
work, I tried it.

I don't want to redesign the form, nor modify a copy of the report.
I tried an idle loop, but can't figure how to break out of it early
when closing the report.

Any suggestions?

Bob Quintal
Nov 12 '05 #1
2 2539
Options here are:

1. If you're using Access 2000 or later you could use the printer object.
It allows you to change the printer a report goes to with ease. See help
for details

2. If you're not using Access 2000 or later you could use API calls to
change the default printer, print the report, and change it back (although
this is somewhat of a pain). The ever helpful Randy Birch has some info on
this at:

http://www.mvps.org/vbnet/index.html...fprinternt.htm

3. Use the report events. Instead of having a loop that just goes on it's
merry way, use the Report's close event to initiate the next report. Messy
but effective.

best I can do at 2351GMT!

"Bob Quintal" <bq******@generation.net> wrote in message
news:37******************************@news.teranew s.com...
I have a report that prints a single record. Normally it's enter
one record, then print it.
This works great.

New requirement: Each record needs to be printed to an individual
.pdf file from any of several workstations. These will be digitally
signed. No problem except that I have been asked to batch all
existing records.

Wrote a code loop that calls the report for each record. Works
great if the acprintnormal option is used, I get a hard copy for
each record.

But: the .pdf driver name varies from machine to machine, so I cant
set it as "Specific printer" in setup.
I cannot force the users to make the .pdf driver their default
printer.

If I open the form in acreportpreview mode, the report opens on the
first record, and I can select the .pdf driver from the menu,
assign the filename, and save the printout, but the loop keeps
going through all the records, not opening them.

If I were looping through a form, opening it in modal view would
work, I tried it.

I don't want to redesign the form, nor modify a copy of the report.
I tried an idle loop, but can't figure how to break out of it early
when closing the report.

Any suggestions?

Bob Quintal

Nov 12 '05 #2
"Ben Eaton" <be************@hotmail.com> wrote in
news:bo***********@news.wplus.net:

Thanks for the tips.
Options here are:

1. If you're using Access 2000 or later you could use the
printer object. It allows you to change the printer a report
goes to with ease. See help for details
Access 97 on WinNT 4.0
2. If you're not using Access 2000 or later you could use API
calls to change the default printer, print the report, and
change it back (although this is somewhat of a pain). The
ever helpful Randy Birch has some info on this at:

http://www.mvps.org/vbnet/index.html...defprinternt.h
tm
This is a pain, but it looks like the best choice.
3. Use the report events. Instead of having a loop that just
goes on it's merry way, use the Report's close event to
initiate the next report. Messy but effective.
Too messy. The report is called from several forms. It is a PITA to
resolve which parent called the report, and bypass the close event
if not from the correct source

best I can do at 2351GMT!
That's not an excuse if you are posting from Australia. (well maybe
hunger pangs are setting in.), but valid if you are sitting at a
desk in Moscow.

But your second suggestion looks like I might be able to do
something with it.

Bob Quintal

"Bob Quintal" <bq******@generation.net> wrote in message
news:37******************************@news.teranew s.com...
I have a report that prints a single record. Normally it's
enter one record, then print it.
This works great.

New requirement: Each record needs to be printed to an
individual .pdf file from any of several workstations. These
will be digitally signed. No problem except that I have been
asked to batch all existing records.

Wrote a code loop that calls the report for each record.
Works great if the acprintnormal option is used, I get a hard
copy for each record.

But: the .pdf driver name varies from machine to machine, so
I cant set it as "Specific printer" in setup.
I cannot force the users to make the .pdf driver their
default printer.

If I open the form in acreportpreview mode, the report opens
on the first record, and I can select the .pdf driver from
the menu, assign the filename, and save the printout, but the
loop keeps going through all the records, not opening them.

If I were looping through a form, opening it in modal view
would work, I tried it.

I don't want to redesign the form, nor modify a copy of the
report. I tried an idle loop, but can't figure how to break
out of it early when closing the report.

Any suggestions?

Bob Quintal



Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

46 posts views Thread by Steve | last post: by
5 posts views Thread by John Bowman | last post: by
6 posts views Thread by Shamin | last post: by
1 post views Thread by Marcolino | last post: by
reply views Thread by kermitthefrogpy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.