server side printing almost working, what's the problem?
-
Further to my last post in here, I've been doing some playing around with various bits of ActiveX and all sorts of other things in an effort to get my app to print nicely rendered text when handed a bunch of HTML. I think I'm pretty close. I managed to get all the bugs I can see ironed out, but now I've got what's either silent failure or a different kind of success than I was expecting. Bear with me while I try to explain what I've done, it's a little unconventional. To test with I've set up a page on which the page load event sends some HTML to my print routine. My print routine consists of a new class which inherits System.Windows.Forms.Form (I know, but bear with me). This class creates an ActiveX object (the MS DHTML editor control), passes the HTML string to it as its content, and then asks it to print. I found that, while there are all sorts of problems with printing without displaying the print dialog from a web browser control, the DHTML editor doesn't seem to mind and gives exactly the same result. Anyway, after a lot of messing around with this (as you can imagine, including a windows form in an ASP.NET app caused me a little confusion), I've got to the point where I can load my page, and no errors arise, but I don't get anything out of the printer either. The ActiveX control is being called fine, there are no errors there, but the printout just doesn't arrive. The app has identity impersonate set to true, so I figured it would use the logged on user's default printer, but that doesn't seem to be the case. My next thought was that it might be using the aspnet process's default printer, if such a creature exists, but I don't know how to test for that. Anyone have any ideas on how to resolve this? I feel like I'm really, really close and just need a bit of a nudge.
-
Further to my last post in here, I've been doing some playing around with various bits of ActiveX and all sorts of other things in an effort to get my app to print nicely rendered text when handed a bunch of HTML. I think I'm pretty close. I managed to get all the bugs I can see ironed out, but now I've got what's either silent failure or a different kind of success than I was expecting. Bear with me while I try to explain what I've done, it's a little unconventional. To test with I've set up a page on which the page load event sends some HTML to my print routine. My print routine consists of a new class which inherits System.Windows.Forms.Form (I know, but bear with me). This class creates an ActiveX object (the MS DHTML editor control), passes the HTML string to it as its content, and then asks it to print. I found that, while there are all sorts of problems with printing without displaying the print dialog from a web browser control, the DHTML editor doesn't seem to mind and gives exactly the same result. Anyway, after a lot of messing around with this (as you can imagine, including a windows form in an ASP.NET app caused me a little confusion), I've got to the point where I can load my page, and no errors arise, but I don't get anything out of the printer either. The ActiveX control is being called fine, there are no errors there, but the printout just doesn't arrive. The app has identity impersonate set to true, so I figured it would use the logged on user's default printer, but that doesn't seem to be the case. My next thought was that it might be using the aspnet process's default printer, if such a creature exists, but I don't know how to test for that. Anyone have any ideas on how to resolve this? I feel like I'm really, really close and just need a bit of a nudge.
If it helps at all, I can now discount the notion that it's going to the wrong printer. I set the default printer programmatically and it still doesn't print anything. Any help would be appreciated, particularly from those of you more familiar with COM and ActiveX than I am.