Question

I’m trying to use an invisible WebBrowser control to print a very simple HTML document. Our application requires that we be able to print several documents this way, and that they all can be sent to different printers. Unfortunately, I haven’t been very successful in making the output go to the right printer.

The way it works right now is that before printing a document, the application determines which printer is to receive it, and sets the default printer accordingly. To do this it uses SetDefaultPrinter() imported from WinSpool.drv. If I step the code in debug mode I can clearly see that the default printer changes (and this change is reflected in the control panel UI), but the WebBrowser still insists on using the original default printer.

The MSDN documentation, from what I’ve seen, doesn’t really provide a solution for this scenario. I would greatly appreciate some input on how I can accomplish this programmatically.

Answer 1

Given what you’ve said, perhaps if you restart the process which contains the web browser control (or the process which is the web browser control), after you change the default printer? That’s the kind of thing I see happening here, for example.

---

I suppose it would be possible to fork off a background process that does the actual printing, but I’m really hoping for a simpler solution.

Forking was my first thought towards a probably-simplest solution.

Some other alternatives are as follows.

1). IE, which the webbrowser control is wrapping, exposes APIs via ActiveX. One of its/those APIs might let you specify the destination printer.

2). Some executables (I don’t know about IE) have printto entries in the registry. For example, Acrobat Reader has an entry whose value is as follows:

""C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe""  /t "%1" "%2" "%3" "%4"

That’s used for specifying the syntax of the command-line which you can use to print and specify a (non-default) printer. You can also Google for printto, see e.g. PrintTo command in the ShellExecute.

3). I have implemented an HTML control for .NET of my own, which doesn’t depend on IE. You say that your HTML (and CSS I presume) are simple, so perhaps I can render it, either out of the box or with only a little extra development effort. I don’t support printing, but printing is quite easy for a user control to implement. Getting me to implement that for you would cost you several hundred but, who knows, maybe it’s worth it to you. It would be quite a light-weight solution, and perhaps well supported. You could email me if you want to discuss that further.

4). You might also find other controls, similar to mine, more or less famous/expensive; or other applications, e.g. OpenOffice etc etc.

5). You could consider converting the HTML (somehow) to another format (e.g. PDF) for which you have an application which gives you better support for printing.