Pop-up message when converting Access report to PDF (1 Viewer)

JTrilloJ

Member
Local time
Tomorrow, 00:27
Joined
Feb 17, 2020
Messages
59
In Access VBA, I have a procedure to convert Access reports to .pdf files.
It works very well for me.The problem is that when I call it repeatedly, I get a pop-up message that I can barely read. In the top left corner, there's an icon, followed by the text >> Print, and in the center, it says something like >> Extracting... (I can't read any more):
it does a good job, but the message for each report is annoying. Do any of you know how to remove it?
The Code
'Para ésta Aplicación necesitaré unas variables Publicas que son >>
Public NombInf As String
Public AñoInf As String
Public MesInf As String
Public DiaInf As String
Public FechaCompleta As String


Public Sub CreaPDFMuniAñoMes()
Dim RutaPDF As String, IzqPDF As String, CentroPDF As String, NombreInfPDF As String, RutaYFicheroPDF As String
On Error GoTo ErrorCreaPDFMuniAñoMes

'Defino la Parte Izquierda como el NombreInforme, pero puede ser Compuesto. En éste caso no lo pongo.
'IzqPDF = NombreInforme

'Defino la parte Central del Informe
CentroPDF = NombInf & AñoInf & MesInf

'Defino el Nombre completo del Fichero que se va a guardar
NombreInfPDF = CentroPDF & ".pdf"

'Defino la Ruta donde están los Ficheros PDF
RutaPDF = Application.CurrentProject.Path & "\InformesPDF\"

'Completo la cadena para guardarlo
RutaYFicheroPDF = RutaPDF & NombreInfPDF 'Sería >> Application.CurrentProject.Path & "\InformesPDF\NombInf & AñoInf & MesInf & ".pdf""
DoCmd.OutputTo acOutputReport, NombreInforme, acFormatPDF, RutaYFicheroPDF, False, , , acExportQualityPrint 'Si se quiere visualizar el PDF >> Poner True

SalidaCreaPDFMuniAñoMes:
On Error GoTo 0
Exit Sub
ErrorCreaPDFMuniAñoMes:
MsgBox "Error " & Err.Number & " en Procedimiento.: CreaPDFMuniAñoMes de Documento VBA: MdlPDF (" & Err.Description & ")"
Resume SalidaCreaPDFMuniAñoMes
End Sub 'CreaPDFMuniAñoMes()
 
I don't see an icon in upper left. All I see, very briefly, is an "in progress" popup with Cancel button. But output is so quick there is no opportunity to even click Cancel if I wanted to.
 
Last edited:
Just look away from the screen 😉 I believe this has been discussed here before with no easy solution.
 
Typically, that message is simply advising you that the conversion is in progress. It's not an error. I don't know if this will actually work, but IF you REALLY want to try to suppress that message, you might try this as an experiment to see if it helps. It is NOT a good idea to suppress warning messages long-term, but you can safely turn off warnings briefly for things you know to be working correctly. IF there is any chance that the .OutputTo could fail, you DON'T want to use .SetWarnings in that case.

Code:
DoCmd.SetWarnings False
DoCmd.OutputTo acOutputReport, NombreInforme, acFormatPDF, RutaYFicheroPDF, False, , , acExportQualityPrint
DoCmd.SetWarnings True
 
Print dialogs such as this are Windows messages. There is no way of suppressing them from Access

1747553272371.png
 
Hello:
Thank you all for your replies.
I imagined it wouldn't be easy.
The message is exactly what Colin shows.
I'd already tried Doc's solution without success.
DHookom's is very good.
The effect June mentions has the added drawback that you can't cancel the task.
Conclusion: Things are the way they are, not the way we want them to be.
Thanks again, everyone.
 
I know from personal experience that the message can’t be suppressed. I have reports of several hundred pages that I convert to PDF and tried hard to find a solution. I did find some old code on a well respected website - it may have been the Access Web. It presumably worked once but it did absolutely nothing in my tests.
 
Thanks, Colin, for the expansion:
The truth is, I've been looking for a solution for a long time.
Now, from your responses, I see that it's not possible at the moment.
Sometimes the flickering is annoying, but I also understand that it's a subjective issue.
It's possible that a solution will emerge one day.
Best regards >> Jacinto
 
There is a registry setting that would allow you to enable or disable Windows error reporting. The same issue that I mentioned about the dangers of disabling Access / Office warnings would apply to Windows errors. You NEVER want that turned off for any length of time. If this becomes something you want to pursue, search for "Disable Windows Error Reporting" and see what it takes. While this IS possible, it is highly NOT recommended.
 
Hi Doc: Thanks for your message.
For now, I'll stick with the part of your text: "You NEVER want that turned off for any length of time."
And I would add, "Not even for a short time."
The risk outweighs the occasional inconvenience.
Best regards >> Jacinto
 
There is a registry setting that would allow you to enable or disable Windows error reporting. The same issue that I mentioned about the dangers of disabling Access / Office warnings would apply to Windows errors. You NEVER want that turned off for any length of time. If this becomes something you want to pursue, search for "Disable Windows Error Reporting" and see what it takes. While this IS possible, it is highly NOT recommended.
Sorry, but I'm not sure of the relevance/point of this comment.
The OP was trying to suppress a Windows print dialog not an error message.
 
Colin, you might well be right - but the articles had several parts to shut down, and it is possible that this would quiet the message. The only other way to do as requested would be if you could find the right driver and check the registry for the corresponding driver options.
 
I tried by hiding the window using Win32 API calls and it does hide the printing dialog but it blocks you from doing anything else while it's running.
After that, I ran a few tests and I think it could be possible to run the export from another instance of the application to avoid dealing with it.

Here's the code that hides the window as mentioned.
Code:
Option Compare Database
Option Explicit

This in a module
#If VBA7 Then
    Public Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" _
        (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr

    Public Declare PtrSafe Function ShowWindow Lib "user32" _
        (ByVal hWnd As LongPtr, ByVal nCmdShow As Long) As Long
#Else
    Public Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
        (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

    Public Declare Function ShowWindow Lib "user32" _
        (ByVal hWnd As Long, ByVal nCmdShow As Long) As Long
#End If

Public Const SW_HIDE As Long = 0
Public ImpresionTimerActive As Boolean


And in a hidden form:
Code:
Option Compare Database
Option Explicit

Private Sub Form_Timer()
    Dim hWnd As LongPtr
    
    hWnd = FindWindow("#32770", "Impresión") ' switch Impresión to whatever you get in your language
    If hWnd <> 0 Then
        ShowWindow hWnd, SW_HIDE
        ' Optional: deactivate timer if you just want one hit
        Me.TimerInterval = 0
        ImpresionTimerActive = False
        DoCmd.Close acForm, Me.Name
    End If
End Sub

Then it's just a matter opening the hidden form and then run the output procedure.

That's why I suppose it'd be better in a new instance.
 
Print dialogs such as this are Windows messages.
Are they?
The process of generating a PDF from an Access report is a pretty specific operation. I doubt there is a Windows dialog that shows up for this without any control from within Access. (I mean Access from Microsoft's perspective, not ours.)
 
I tried by hiding the window using Win32 API calls and it does hide the printing dialog but it blocks you from doing anything else while it's running.
What timer interval did you set?
Maybe it would work less invasively with a longer interval?
Did you try to add DoEvents to the TimeProc to enable Access to process other operations while the time is running?

I like your approach very much.
It would be better to identify the dialog window by other attributes than the localized window title.
 
I haven’t yet tested Edgar’s code but from his comments it appears I was wrong and that the message can be suppressed, albeit with an undesirable side effect. If that can be overcome, then I’m all for it!
 
Thanks Edgar for your contribution.
I'll try it. As Sonic8 mentions, I'll introduce a DoEvents as a precaution.
From Colin's post, I gather he'll try it too.
We'll see the results. Best regards.
 
I leave you with a playground file, if want to test, just open form1.

I tried adding a DoEvents command in a few places of the code, but it did nothing in my tests. You could probably find where it should go with more precision. Here's what my playground setup does:
1. Open form1
2. Click on button
3. The print window flashes for a moment and then the code hides the entire Access application.
4. You can return to Access but it will block you from doing anything until the print window (now hidden) is done, the report contains 10k records, so the printing takes a while.

I'm using 1 ~ 10 as timer interval.

I got the #32770 class name from the Inspect tool installed by the windows SDK, I think it comes with Visual Studio, but I'm not sure. The tool lets me check what's under my cursor, so I just hovered over the print window and it returned that class name along with a bunch of other info. The print window appears to be a part of Access by the looks of what the Inspect tool shows.

I believe using another instance of Access could be a better approach.
 

Attachments

Just tried the above example app supplied by @Edgar_

I altered the somePath line to match my desktop location as I was getting error 2501 when the PDF was completed

1. For initial testing I ran the code as supplied. The Printing dialog appears as normal and the PDF is created after just over 10 seconds
2. Changed the line in the hidden form timer event to hWnd = FindWindow("#32770", "Printing"). The dialog appears briefly then disappears. Access is no longer the active window and the action cannot be cancelled. PDF created as above
3. Changed the TimerInterval to 1 then 10. Can't see any difference in behaviour. Similarly with DoEvents

I tried cancelling by holding down Ctrl+Break whilst the PDF was being created, but the 'code has been cancelled' message only appeared after the PDF was created

In summary, this code does suppress all except the initial part of the printing dialog. The problem for me is that it apparently can't be cancelled
 
I've tried Edgar's solution and it seems fine to me.
However, compared to:
DoCmd.SetWarnings False
'Code
DoCmd.SetWarnings True
Which is quite "clean," it doesn't seem like the definitive solution.
Still, Edgar's work is appreciated.
Best regards.
 

Users who are viewing this thread

Back
Top Bottom