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?
I am having the same problem. My .NET app used axAcroPDF.printAll to silently print a PDF. Work just fine until I installed 8.0 (or perhaps 8.1.0, I can't tell). Now the Adobe Reader window opens (empty) and stays visible. How can I either close it automatically or keep it from displaying?
"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 !
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.
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)
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.
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 @ email@example.com) 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:
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).
Christopher, I have not installed 9 on my development PC to test this so I was curious if your solution pops up the printer dialog box or simply sends the report directly to the users default printer using the printers current default settings?
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.
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.