What printing API are you using from .NET? Are you working with Acrobat or Reader?

Please provide more details...

Leonard

OK, so you are working with the AcroPDF.dll - the ActiveX control. As such, I don't understand how you are seeing an Acrobat window - since there isn't one present.

Leonard

You mean that your form with the view of the PDF comes up, correct? That is expected behavior in order to prevent "rogue applications" from doing something that users are not expecting.

Leonard

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
Try
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)
End Try
End Sub

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

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.

AxAcroPDFLib.AxAcroPDF axAcroPDF;
string reportFilename = reportPDFPath + ".pdf"; this.CrystalReportDocument.ExportToStream(ExportFormatType.PortableDo cFormat);
this.CrystalReportDocument.ExportToDisk(ExportFormatType.PortableDocF ormat, reportFilename);
axAcroPDF.LoadFile(reportFilename);
axAcroPDF.printWithDialog();

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.

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?

Aandi Inston

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)
End If

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.

Thanks

Hello,

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

When you bring up the print dialog, Windows also brings to the front the parent of that dialog...There is nothing you can do to avoid it - it's the OS...

Leonard

Inspired by this thread I started to look into this again, here are my observations:

1. If you are writing a plug-in, you could simply execute a this.print(); JavaScript code line. This also brings up the print dialog with the correct presets and does NOT display the Acrobat main window (which confirms that this is NOT an OS issue).

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 :-(

Steffen.

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 @ steffen.kuhnt@ajila.ch) 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.printWithDialog;
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).

Is there any update on How we can hide adobe reader 8.0 window during print?

In reader 9 this works...

Dim frmPDFViewer As New frmPDFViewer()
frmPDFViewer.pdfViewer.src = file_dir & file_name
frmPDFViewer.pdfViewer.printAll

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.

> 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.

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.