UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Repress The Print Dialog When Exporting To Pdf, Access 2013    
 
   
steadyyeti
post Nov 14 2017, 08:52 AM
Post#1



Posts: 40
Joined: 8-December 08
From: London


I have some VBA code that loops through a list of around 20,000 customers, produces a report for each one and exports to a *.PDF

Takes approx. 0.8 seconds to generate / export each report and all works fine - provided nobody touches anything!

However whilst getting on with my "other work" in the meantime it's all too easy to inadvertently hit the "Cancel" button on the "Printing" dialog box that pops up for each individual export. Very frustrating.

Workaround: I have a log table that records which reports I have already generated so can pick up where I left off rather than starting from scratch every time - however I was wondering if anyone knew of a way to repress the dialog box so that it just runs quietly in the background until it's finished? "SetWarnings" seems to work for everything else - but not this.

Thanks in advance.

Tim
Go to the top of the page
 
GroverParkGeorge
post Nov 14 2017, 09:13 AM
Post#2


UA Admin
Posts: 31,216
Joined: 20-June 02
From: Newcastle, WA


Please show the code where you are doing this, the entire Sub or Function.

Thanks.

--------------------
Go to the top of the page
 
steadyyeti
post Nov 14 2017, 09:57 AM
Post#3



Posts: 40
Joined: 8-December 08
From: London


Thanks George.

It's running now (and I'm trying not to interrupt it!) - however the line of code in question is a simple DoCmd.OutputTo... command.

Takes an Access report, saves it as a PDF, export location set by a string variable based on a specified network folder and a combination of customer account number / customer id / name.

Next time it falls over I'll copy the actual code - hopefully that's enough to be going on with in the meantime.
Go to the top of the page
 
GroverParkGeorge
post Nov 14 2017, 10:20 AM
Post#4


UA Admin
Posts: 31,216
Joined: 20-June 02
From: Newcastle, WA


Unfortunately, without knowing how the entire procedure works, we simply can't offer detailed suggestions about it. So, please do give us the chance to review the function, or sub, and offer ideas on what you might do to resolve this issue.

--------------------
Go to the top of the page
 
River59
post Nov 14 2017, 10:31 AM
Post#5



Posts: 1,347
Joined: 7-April 10
From: Detroit, MI


I'm sure that George will help you pinpoint what is going on but I wanted to point out a couple of things. First, why are you getting the Print diaglog box? Two things can be happening here that are slowing you down (8 sec to process each rpt seems like a lot).

First - Do not open the report in Access before sending to PDF
Second - Are you setting PDF opening as False?

Here is how I do it to process around 250 recs in a few seconds:

DoCmd.OutputTo acOutputReport, "RptInitialNotification_e", acFormatPDF, FilePath, False

Good luck!

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
GroverParkGeorge
post Nov 14 2017, 10:34 AM
Post#6


UA Admin
Posts: 31,216
Joined: 20-June 02
From: Newcastle, WA


Good points, thanks.

--------------------
Go to the top of the page
 
steadyyeti
post Nov 14 2017, 11:48 AM
Post#7



Posts: 40
Joined: 8-December 08
From: London


Thanks all.

I didn't want to clutter this post with lots of irrelevant code, so here's a quick summary of what it does...

- Opens an ADODB recordset from the back end SQL Server DB, approx. 20,000 customer records at a time
- Loops through the records to return the key information to run the report
- Drop / re-create the pass-through source queries for the report with the specific customer details

...then the single line with the issue...

DoCmd.OutputTo acOutputReport, REPORT_FURTHERS_OF, acFormatPDF, strFile, False

("REPORT_FURTHERS_OF" is a constant defining the report name, "strFile" is a concatenation of various attributes to give the full path, file name and *.pdf extension for the export)

...then logs the export file name / location / etc in an audit table when finished.

Each iteration of the loop takes approx. 0.8 (not 8!) seconds. I can live with that - I only need to run the whole lot once or twice a month, the rest of the time it's just the odd ad hoc version of the report for one or two customers at a time.

It's just that every time it exports a PDF it displays a dialog box "Now outputting..." with a cancel button - I just want to stop that from popping up if possible.
Go to the top of the page
 
River59
post Nov 14 2017, 01:50 PM
Post#8



Posts: 1,347
Joined: 7-April 10
From: Detroit, MI


Sorry, steadyyeti, my reports run so fast this message is a flash on the screen. They would have to give you a prize if you were able to hit the cancel button. I did some digging and the consensus seems to be that you cannot suppress this message. Maybe someone else here can offer you a different solution.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
PhilS
post Nov 14 2017, 02:16 PM
Post#9



Posts: 404
Joined: 26-May 15
From: The middle of Germany


QUOTE
my reports run so fast this message is a flash on the screen. They would have to give you a prize if you were able to hit the cancel button.

Just press (accidentally) the [ESC] key while the printing process runs. - Can happen easily if you print a large number of reports.

However, canceling the OutputTo will raise a run-time error 2501 (...action was canceled). So, if you handle this error and allow the user to continue/restart the printing process where it was interrupted, the issue should not be too severe.

--------------------
Go to the top of the page
 
River59
post Nov 14 2017, 04:01 PM
Post#10



Posts: 1,347
Joined: 7-April 10
From: Detroit, MI


Like I said, my database runs so fast it is pretty easy to keep your hands off the keyboard while it generates the reports. The OP, on the other hand, is running a longer process so it could become a problem. Didn't intend to mislead.

--------------------
Remember ... Armstrong, Aldrin and Collins flew to the moon and back with a computer system less complex than a modern, programmable toaster ...
Go to the top of the page
 
steadyyeti
post Nov 16 2017, 05:20 AM
Post#11



Posts: 40
Joined: 8-December 08
From: London


OK - thanks everyone - yes PhilS that's effectively exactly what I'm doing - handling the error and allowing a restart at the point it fell over by comparing against the log table.

If anyone has a fix for this please do let me know - but yes from reading various other related posts elsewhere it simply doesn't exist. I'll live with it.

Tim
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    14th December 2017 - 11:17 PM