So it seems to me that the problem is with a dialog box. When we fixed the problem with the dialog box, presto, the automatic process would not halt.
When opening, printing and closing these problem files manually, we would often get a dialog box. Using the above method, we observe that certain MS Office files can halt the automatic printing process in iframes in IE. I think this may only be an option in IE6, unfortunately.īy the way, this why I’m not a frontend developer. So I ended up including good old empty hyperlinks to content alongside iframes displaying the same content, and I ask my users to check the “Print All Linked Documents” option in their print dialog options tab. Of course, this solution is silly, like a poor Dickensian cobbler using one shoe to pound nails into the sole of another shoe. Whatever is going on, I’m sure there’s a good reason, iframes are evil, and it will be all fixed in IE7… Perhaps because of cross site scripting, or perhaps because of bad beans. Also, the backend developer in me was suspicious of the “focus”: if I’m giving an iframe object to its print() method through the implicit “zeroth” argument, why does it need to have focus()? Unless print is not a really method of iframe, iframe.print() is just fake javascript sugar on top of an overload of window.print(), and the window overload doesn’t actually take iframe as an argument. How did I find that out? I was a desperate man, grasping at straws. Hmmmm.) It turns out that the following solution does work: (90% of the forums I sampled that suggested something along the lines of the above stopped at one iframe. It took an hour and a ream of paper, but it turns out that the problem is that the iframe you want to print has to be in focus when you hit the print button on the print dialog. So what do you get when you display this page in IE6 and click the “Print All” button? I got a few print dialogs to which I answered “Print”, I got the “H! I’m a report!” page, and I got the contents of the second iframe, iframe #2, twice. (Second and a half: I closed the iframe tag with a instead of making it an empty tag on purpose. Second, the print job needs to know which iframe to print, so don’t forget to give the iframe focus before printing it. Not a problem if you’re operating within a single domain. This is denied to prevent cross site scripting attacks. First, you’ll want to watch out for “Access Denied” javascript errors if you try to print iframes displaying content from other sites. (In the following, ServeFile.ashx is n ASP.Net web handler that serves files, but you could replace it with whatever URL suits you on your domain.) Here is a sketch for a sample report with two attachments. Implementing this solution is easy using iframes. Being a pure “web” solution, I was less familiar with the technical challenges, but I learned quickly this afternoon. My second approach was to display the attachments in IFrames, with printing handled by my nemesis, Javascript. Using client side COM Interop seemed promising, but the early results were mixed as I didn’t like the formats and it seemed like it was the start of a slippery slope of endless tweaking. However, as I found out previously, using COM Interop to do conversions on the server is neither supported nor very stable.
This would allow content to be displayed inline and print from the familiar Print function in the browser. My first approach was to look into converting Word and Excel on the fly into text or HTML. I can (thankfully) make a few simplifying assumptions: I am working with ASP.Net 2.0 in an inernal environment where I can assume everyone is using IE6.0.
So naturally the users want everything to display inline and print from a single button. The attachments are primarily Microsoft Office documents with a few JPEGS and plain text thrown in. Briefly, I have a web application which allows users to build an HTML report from various dynamically generated ASP.Net forms, and users have the ability to upload attachments to the report. But sometimes, like today, I have to wade right in. I have no stake in the debates over liquid design versus tables, or over the inherent evilness of frames and iframes. I’ve always thought of myself as an enterprise architect first, and a backend programmer second. First I should admit that I don’t think of myself primarily as a frontend web developer.
0 kommentar(er)
