Intercept the Print message in C#

[=?Utf-8?B?QnJ5YW4=?=]

I have an application that hosts a web browser control. I would like to
detect when ever the browser tries to print a page and rather than print the
document, store the print job off in a database for printing at a later time.
There are some other controls in my application that the user could print
from, so I can't have this specifically coded to the browser control. It
need to intercept any print message generated from my application. I realize
this will probably take some Interop code. Any hints or suggestions would be
appreciated. Thanks!!

[Nicholas Paldino [.NET/C# MVP]]

There is also the option of creating a print driver of some sort which
will basically act as a virtual printer (something like the PDF print option
that Adobe offers).

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael B. Trausch" <mi**@trausch.uswrote in message
news:20081111163230.7dc690f0@zest...

On Tue, 11 Nov 2008 13:02:02 -0800
Bryan <Br***@discussions.microsoft.comwrote:

>>
I have an application that hosts a web browser control. I would like
to detect when ever the browser tries to print a page and rather than
print the document, store the print job off in a database for
printing at a later time. There are some other controls in my
application that the user could print from, so I can't have this
specifically coded to the browser control. It need to intercept any
print message generated from my application. I realize this will
probably take some Interop code. Any hints or suggestions would be
appreciated. Thanks!!

If your application is hosted in a standard Web browser, you will not
be able to intercept the native (browser-provided) print menu item or
icon press. You can have a button in your application that will do
this, but I would advise calling it something other than "print", since
that would cause confusion.

It seems that IE6 supports such a thing, but it's not a
standards-compliant feature (that is, it's a proprietary extension).
Firefox and other standards-compliant browsers don't support such a
hook (and personally, I would disable it if they did, it's a plain
privacy violation; it's nobody's business if I print a page on
Wikipedia or anything else on the Internet).

If having a button or widget in your application doesn't make sense for
what you're doing, I'd consider not using a Web application at all,
instead using a "fat" client to handle whatever client-side work you're
doing. Again, I'd recommend not using "Print" as the toolbar or menu
item because the meaning of such a button is expected to be consistent
with other applications; if you want to direct something to a spool
elsewhere than a print button would traditionally go (to the local
print spool), you should have another name for that command.

--- Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/

[Nicholas Paldino [.NET/C# MVP]]

All true, but since the OP indicated that the application hosts a web
browser control (the WebBrowser control that I assume), I would assume that
there is ^some^ degree of control of the client execution environment (or
more specifically, that there is an install of some sort where the driver
can be installed, it doesn't have to be set as the default).

Also, since it is a .NET app, this wouldn't be the only cross-platform
concern if the app were ported.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael B. Trausch" <mi**@trausch.uswrote in message
news:20081111164705.6c7b44ce@zest...

On Tue, 11 Nov 2008 16:36:14 -0500
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com>
wrote:

>>
There is also the option of creating a print driver of some sort
which will basically act as a virtual printer (something like the PDF
print option that Adobe offers).

This assumes total control of the client execution environment, whether
or not the user is doing this is undetectable from the Web application
itself. Also, since it'd be a global setting, may cause far more
trouble than solving the original problem... and, of course, such a
solution is system-dependent. You lose portability if you depend on
being able to deploy something like this across clients, since print
configuration is not inherently cross-platform.

--- Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/

[=?Utf-8?B?QnJ5YW4=?=]

Thanks for all of your replies!.. Yes, my application would have total
control of the WebBrowser control. If the user were to print the current
page, or open a Word document within the control and print it, I would still
like to detect this. I would like them to get the normal PrintDialog, select
their settings and *Print*. I want to capture this print object and stuff it
in the database without actually printing. Is this possible?.. The users
would understand that this is a feature of the application and not a *normal*
printing method.

"Nicholas Paldino [.NET/C# MVP]" wrote:

All true, but since the OP indicated that the application hosts a web
browser control (the WebBrowser control that I assume), I would assume that
there is ^some^ degree of control of the client execution environment (or
more specifically, that there is an install of some sort where the driver
can be installed, it doesn't have to be set as the default).

Also, since it is a .NET app, this wouldn't be the only cross-platform
concern if the app were ported.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael B. Trausch" <mi**@trausch.uswrote in message
news:20081111164705.6c7b44ce@zest...

On Tue, 11 Nov 2008 16:36:14 -0500
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com>
wrote:

>
There is also the option of creating a print driver of some sort
which will basically act as a virtual printer (something like the PDF
print option that Adobe offers).

This assumes total control of the client execution environment, whether
or not the user is doing this is undetectable from the Web application
itself. Also, since it'd be a global setting, may cause far more
trouble than solving the original problem... and, of course, such a
solution is system-dependent. You lose portability if you depend on
being able to deploy something like this across clients, since print
configuration is not inherently cross-platform.

--- Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/