Print PDF file from VB6
stu
existing pdf file from within a VB6 application (win2k & winXP).
I would like to print this file with no interaction from the user.
The pdf ocx (ActiveX control) is useless! You may load a file but the print
method does not (and is not supposed to) work.
Shelling the command:
acrord32.exe /t <pdf_path> <printer_name> <driver_name> <port>
does work in win2k. It prints the <pdf_path> file without any user
interaction. The problem with this solution becomes apparent when you move
to WinXP. the /t should not display acrobat reader, but in xp it does.
This is a problem because the user is working away then when we print a pdf
"in the background" it (acrobat reader) flashes up as the top most window
stealing focus.
The SDK methods look great but you need the full acrobat not the free
reader. And you need a licence for every user. No server editions exist.
So this is far too expensive!
Are there any ocx that let me print a pdf? Can I stop the reader from
flashing up when printing from a shell in xp?
All I want to do is print an existing pdf file. It is crazy that i need to
buy a licensed product for this! Can anybody give me any suggestions?
Cheers
Stu
Ben Amada
If Adobe is installed on the machine, you can use the ShellExecute API with
the "print" parameter. Here's an example -- note that the print example in
the below link prints a .DOC file, but you can just replace this with a .PDF
file.
http://www.vbaccelerator.com/codelib/shell/shellex.htm
--
Ben
Aandi Inston
>The SDK methods look great but you need the full acrobat not the free
>reader.
Not to use selected DDE methods. Some DDE (as per the IAC Reference)
does work in Acrobat Reader.
----------------------------------------
Aandi Inston qu...@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.
stu
"Ben Amada" <b...@powerpick.com> wrote in message
news:ecGc7zI5...@TK2MSFTNGP12.phx.gbl...
> stu wrote:
>
> If Adobe is installed on the machine, you can use the ShellExecute API
with
> the "print" parameter. Here's an example -- note that the print example
in
> the below link prints a .DOC file, but you can just replace this with a
> file.
>
> http://www.vbaccelerator.com/codelib/shell/shellex.htm
>
> --
> Ben
Works great but it shows the reader while printing and so steals focus from
whatever the user is doing. I would like to print in the background.
After testing the original code I edited
ShellEx txtFile.Text, , , , "print", Me.hWnd to the next line
ShellEx txtFile.Text, essSW_HIDE, , , "print"
But this still displays the reader. Any ideas?
Cheers
Stu
Ben Amada
Stu,
The essSW_HIDE option was a good idea. Actually, stepping through the
sample ShellEx function on the link I posted, it looks like the essSW_HIDE
parameter that you are passing in is ignored. :) The logic in the function
says that if 3rd and 4th parameters are empty strings, then the line of code
that will be executed is:
ShellExecuteForExplore(Owner, sOperation, sFIle, 0, 0, essSW_SHOWNORMAL)
In other words, the essSW_HIDE parameter is never used. I would try
changing that line to:
ShellExecuteForExplore(Owner, sOperation, sFIle, 0, 0, essSW_HIDE)
I didn't actually try printing a PDF, but this *might* work.
Regards,
Ben
stu
> Stu,
>
> The essSW_HIDE option was a good idea. Actually, stepping through the
> sample ShellEx function on the link I posted, it looks like the essSW_HIDE
> parameter that you are passing in is ignored. :) The logic in the
function
> says that if 3rd and 4th parameters are empty strings, then the line of
code
> that will be executed is:
>
> ShellExecuteForExplore(Owner, sOperation, sFIle, 0, 0, essSW_SHOWNORMAL)
>
> In other words, the essSW_HIDE parameter is never used. I would try
> changing that line to:
>
> ShellExecuteForExplore(Owner, sOperation, sFIle, 0, 0, essSW_HIDE)
>
> I didn't actually try printing a PDF, but this *might* work.
>
> Regards,
> Ben
>
>
Just realised this. Build a test program with
ShellExecute Me.hWnd, "print", Text1, 0, 0, SW_HIDE
under a button. Works ok but i get the following issues i would like to
clear:
1) Hides acrobat as long as the user does not have acrobat open, in which
case it steals focus when printing.
2) Even though acrobat is hidden it still steals focus no matter what app
you are using! ATM im writing this with ShellExecute Me.hWnd, "print",
Text1, 0, 0, SW_HIDE under a timer event in VB6. timer interval = 1000
(1sec). Every 1 sec outlook express looses focus briefly while acrobat
prints. You could not work like this! Try it. It will drive you daft!
Is there anyway I can force my application not to steal focus? Ive got
tweakui installed and there is an option to stop other applications stealing
focus but it does not work with this demo.
Would it be within the licence agreements to have a print server that uses
shellexecute to make acrobat reader _only_ print pdfs?
Any ideas?
Cheers
Stu
Ben Amada
Stu,
Thanks for the update. If you don't find any other solutions, one idea is
to try and force your VB app to keep focus. This can be done a number of
ways. For instance, you can have a timer set at a very short interval and
the code to execute when the timer fires could just be "Me.Show" to show
your form. You could also look at subclassing to catch and kill any Windows
messages which indicate another application window will be activated (I
think the msg. in this case is WM_ACTIVATEAPP).
This is all that comes to mind right now :( ... I hope you can find an
adequate solution!
Ben
Comex
You can use Me.SetFocus as an easier solution, but it's still probably
annoying...
--
1.41421356237309504880168872420969807856967187537694
jaf
Have you tried the /h (hidden) switch?
--
John
johnf202 at hotmail.com
"stu" <smcg...@nospam.co.uk> wrote in message
news:b49os6$2v0$1$8302...@news.demon.co.uk...
stu
"jaf" <m...@here.com> wrote in message
news:eqBJ0CL5...@TK2MSFTNGP12.phx.gbl...
> Hi Stu,
> Have you tried the /h (hidden) switch?
yip. it still shows! good ehh?
Im going to look into sub classing along with Ben's suggestions on using
shellexecute.
Cheers
Stu
Ben Amada
> You can use Me.SetFocus as an easier solution, but it's still probably
> annoying...
Yeah, thanks -- When I wrote Me.Show, I was thinking there was another more
"intuitive" method (SetFocus), but couldn't come up with it at the time :)
Ben