This content has been marked as final. Show 39 replies
OK what we want to achieve is to open the print dialog without opening the viewer.
What we did was embed acrobat as activeX on a form
Friend WithEvents pdfViewer As AxAcroPDFLib.AxAcroPDF
and issue these commands on a separate form to call the print dialog.
These were codes thats work perfectly fine before.
Dim frmPDFViewer As New frmPDFViewer()
frmPDFViewer.pdfViewer.src = file_dir & file_name
what was happening was acrobat viewer opens with the print dialog which was never an issue before with previous version of acrobat.
Again thanks in advance
Rogue applications?? Leonard, what you are saying is that versions 5, 6, and 7 were broken and now with version 8 this has been fixed.
I think you are wrong. What "rogue" application is going to utilize your PDF printing and why for that matter??
In versions 5 through 7 when the PrintWithDialog method of the Acrobat activeX was called the only thing the user was presented with was a print dialog box that showed a nice little copy of the PDF in the lower right corner and print options.
Now with version 8 we get the print dialog box popup and the ENTIRE ACROBAT application fires up with nothing in it.
Why would anyone even bother calling the PrintWithDialog method of the activeX control when the entire application is going to open anyway?
I have read some of the "work-arounds" which do not take into account that unless the user is familar with the document they are about to print, simple settings like landscape or portrait is a shot in the dark.
Has the acrobat team mentioned anything about this? Is there a FIX planned?
"PrintWithDialog" definitely opens the Acrobat Reader V 8 window. You can close it, e.g. when your form closes:
Public Declare Function apiSendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Integer, ByVal wMsg As Integer, ByVal wParam As Integer, ByVal lParam As String) As Integer
Private Sub Form1_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
Const WM_CLOSE = &H10
Dim myHandle As Integer = 0
myHandle = apiFindWindow(vbNullString, "Adobe Reader")
If myHandle > 0 Then apiSendMessage(myHandle, WM_CLOSE, CLng(0), vbNullString)
Catch ex As Exception
MsgBox("Error: " + ex.ToString)
The problem I encounter is that the print dialog does not show a preselected print range of "all pages", but of page 1 only. Does somebody know how to influence this setting before calling "PrintWithDialog"?
BTW, I had some difficulty to find AcroPDF.dll for Reader version 8 on my system, until I finally located it in C:\Program Files\Common Files\Adobe\Acrobat\ActiveX !
Peter thanks for the suggestion .. =)
regarding your problem on
"The problem I encounter is that the print dialog does not show a preselected print range of "all pages", but of page 1 only"
what i did was after printwithdialog shows I performed a sendkey command.
hope this works for you as well.
How to approach Send Keys for Enter to Print Dialog in C# Windows Application. I am using AxAcroPDFLib.AxAcroPDF library to open the crystal report in PDF browser control.
string reportFilename = reportPDFPath + ".pdf"; this.CrystalReportDocument.ExportToStream(ExportFormatType.PortableDocFormat);
I tried to use SendKeys before and after axAcroPDF.printWithDialog() but there was no use.
When Print Dialog window opens by default PRINT RANGE Selecting PAGES.
But my requirement by default in PRINT RANGE is ALL.
So please help me out how to use SendKeys for Enter onto to PRINT DIALOG Window.
Have u got any solution for "
Hide Acrobat When/After Printing PDF with printdialog" I am also facing same problem in C# code.
I have also posted query for this as title "IAC Open function of Acrobat8.0"
I have not found any good workable solution for this.Any help in this would be gr8ly appreciated.Thanks
We are having a problem with Reader v 8 print dialog box getting lost in the background. We are running a ColdFusion application and users have Windows XP. When the Acrobat print dialog box pops up, it allows you to click on another screen in the background, and at that point the only way to get back to the print dialog is by closing every window, including the application you are using, until the dialog is the last one left! There is no indication in the taskbar that the dialog is open, so users are complaining that the application is not working.
This problem did not exist in version 7. Are there any plans for a fix? Soon? Our users are not technically savvy, and this is a statewide application for the Dept. of Corrections, of critical importance.
I'm having this problem with all of the print*() methods. Also, its my understanding that calling AcroRd32.exe with the /t option should print the document and then terminate the app. The app does not get terminated. And calling it with "/p /h" should print the documetn and hide the app. This does not hide the app.
In short, any method that I choose for printing a PDF from my application ends up with an empty instance of Reader open in front of my application.
>. Also, its my understanding that calling AcroRd32.exe with the /t option should print the document and then terminate the app.
Where does this understanding come from?
> In short, any method that I choose for printing a PDF from my application ends up with an empty instance of Reader open in front of my application.
Have you tried using supported SDK methods to print then close?
Close Adobe After Printing VB .NET
Finally figured out how to close that extra Adobe window after printing! It's crude though ... We're talking user32 API. See code below:
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Integer
Private Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal hwnd As Integer, ByVal wMsg As Integer, ByVal wParam As Integer, ByVal lParam As Integer) As Integer
Private Const WM_CLOSE As Integer = &H10
Dim hWnd As Integer = FindWindow(vbNullString, "Adobe Reader")
If hWnd <> 0 Then
PostMessage(hWnd, WM_CLOSE, 0, 0)
Seems to work well. Any suggestions let me know!
Even I am getting the same problem.
I am also using printwithdialog() option of adobe pdf reader.
If I close the window using User32 dll it's closing the print dialog too.
I dont know when to actually close the window, as printwithdialog() does provide any dialog result or any other information so that one can know the document has been printed.
> I dont know when to actually close the window, as printwithdialog() does provide any dialog result or any other information so that one can know the document has been printed.
You can monitor the print spooler:
You don't need to wait for the job to finish printing, it's safe to close the window when spooling is complete.
Also, if you use Adobe's DDE interface, the printing methods will return when spooling is complete. See pdfp here for an example:
I'm having the same problem in my application to.
But the strange thing is: when i open one of the VB samples
provided with the SDK and i say .printwithdialog Acrobat Reader
does NOT fire up, When i use the code EXCACT the same code
in my own program it does fire up Acrobat Reader.
I can't make any sense of it any more.
I'll try if i can find any differences in my code compared
to their provided sample, ifso I will post it here,
hoping i could help someone else with this problem
I'm having the same issue. The external window shows up regardless if I'm trying to use OLE (printwithdialog) or even an own plugin (AVDocPrintPagesWithParams). This is completely annoying -- so far, I send a keycode (Ctrl+P) to the embedded control as a workaround, but I don't think of this as a workable solution.
If anyone has solved this, please let us know.
If it did not happen with the previous version of acrobat while running on the same OS then it would logically be a change in Acrobat version 8 that is the cause.
The Operating System is only reacting to changes that were made to Acrobat 8.0
Since acrobat 9 is already out I doubt we will ever see this problem fixed in version 8.
Inspired by this thread I started to look into this again, here are my observations:
2. Sending an Ctrl+P keycode to the embedded window does also work, but I would not like to put a solution like this into production.
3. I've had some degree of succes with setting the embedded control to invisible, calling printwithdialog and then setting it back to visible immediately. This also activates the main window, but in the background, so you can find and close it later. This works for me, but I'm pretty sure that this might react differently on different OSes :-(
1. If you're writing a plug-in, use AVDocPrintPagesWithParams() and have it display a dialog.
2. Definitely never put something like that (I'm assuming via SendKeys) into production.
3. Decent solution, but only for printing with a dialog. I haven't figured out why, but doing the same thing with a silent print (printAll for example) will not work. Would you be able to share your code for this method so that I can see if we were going about the rest in the same way?
I have found that sending an SW_HIDE via ShowWindow (imported from user32.dll) does seem to make Reader 8 hide, but only if you send it after Reader has initialized. It seems to ignore hide commands only during init.
1. Using AVDocPrintPagesWithParams() was the first approach that I had chosen, but that also fires up the main window. Using the JS-command was the only way I found to have ONLY the print dialog on my screen. I played around with the AVDoc.. parameters, like altering the parent windows etc., but to no avail.
2. No, it's not SendKeys but I assume it works similar, even though it's an own creation (sending Windows commands using API functions).
3. Sharing code would be OK (drop me an email @ firstname.lastname@example.org) but I'm afraid you'd be disappointed, as it's nothing spetacular. The respective client-side component is a Delphi form, which does the following:
Self.objPDF.Visible := FALSE;
Self.objPDF.Visible := TRUE;
The effect is that you don't see the control disappear, but the main dialog seems to be activated in a hidden state for some reason. Afterwards, you can find it and send a WM_CLOSE to it. However, I'm almost sure that this will not work in an identical fashion on other Windows installations (I needed to use Vista).
As per the documentation, the printAll method is for silent printing - it will not display a dialog to the user.
> Prints the entire document without displaying a user dialog box. The current printer, page settings, and job settings are used. This method returns immediately, even if the printing has not completed.
PDL, you are correct, the documentation does say that. However, as per the documentation, the PrintwithDialog is ONLY supposed to open the printer dialog box, but we all know in version 8 it opens an Adobe window with nothing in it - thus this entire thread.
Since PrintwithDialog does not actually do what the documentation says it does, I am still curious as to what exactly is happening with Christophers solution in version 9.
Have you tested this with version 9?
> ONLY supposed to open the printer dialog box
Where in the documentation does it say that? The dialog it displays is a child of the Reader process, so it would have to display Reader in order to spawn the dialog (this could be within the ActiveX control, but it still needs to be displayed - depends on how your project is setup). I see nowhere in the documentation that it says it would not show the dialog inside Reader - can you point me to where you found this information?
> but we all know in version 8 it opens an Adobe window with nothing in it
We don't all know that - it works fine for me when using the ActiveX control. In fact, the AcrobatActiveXVB samples that comes with SDK 8 uses printWithDialog, and it works the way it is intended. Are you trying to do it with the control hidden? That will not work, since there is no DC (device context) for Reader to draw the dialog to. How would you expect a modal dialog to display from an application that has no view pane? If you could explain how you would get around this from the application level (knowing that the ActiveX control is simply a bridge to a backgrounded Reader process and not its own application), I can certainly take it up as a suggestion.
If you have any experience with MFC applications, think of the viewable portion of the ActiveX control as a CClientDC class. It doesn't use that class specifically (nor is it an MFC app, I'm sure you know this but just to clarify for future readers of this thread), but it may help you draw parallels.
If you look through this entire thread you will see that the conditions you are having is not the same as many of us here.
The documentation of PrintWithDialog for version 9 is:
Prints the document according to the options selected in a user dialog box. The options include embedded printing (printing within a bounding rectangle on a given page), as well as interactive printing to a specified printer. This method returns immediately, even if the printing has not completed.
" I see nowhere in the documentation that it says it would not show the dialog inside Reader - can you point me to where you found this information? "
You are correct and you certainly see nowhere in the documentation that states it will open a window.
I understand what you are saying. However having an empty window open up that the user must close has been something new for most of us since version 8.
Do a search on the problem and you can read the posts for yourself. You and I going back and forth like this is not productive for anyone.
> If you look through this entire thread you will see that the conditions you are having is not the same as many of us here.
I understand that. What you want to achieve can be simply done with Acrobat, but when limited to only the Reader ActiveX control there are limitations. You have to work within the bounds of what the control can provide.
> However having an empty window open up that the user must close has been something new for most of us since version 8.
It is new in version 8, yes. This was done for security reasons. The reason being the possibility of malicious software being developed. I don't want to give anybody ideas for a malicious application on a public forum, but if you want a full explanation personally I would be happy to contact you.
At least this way the user knows what's happening, and your average Joe who doesn't know about task manager can still right-click in the taskbar and close Reader to solve the problem. It balances worldwide user security against a small usability feature for Acrobat SDK application developers that are limited to only developing for Reader and yet again only when using silent printing. As I'm sure you can appreciate and understand, worldwide security won that battle - Reader is a secure product and its intention is to stay that way.
Is it a nuisance? Yes, a very minor one in most cases. However, there are workarounds. If you're developing with VB, what is stopping you from moving the window offscreen during print, monitoring the print queue, and terminating the Reader thread when it is done spooling? It is extra work for the developer, yes - but the fact is, security has to be at the forefront and it is unfortunate that you as the application developer have to do extra work in order to maintain the high level of security expected by Reader users.
If you have suggestions for a secure alternative approach, I am honestly glad to hear them if you care to discuss them.