In the last post, I was clearly overjoyed with my new HTTP handler to deal with some PDF display issues. This thing worked exactly as I had hoped it would on my development box running from the IDE. Unfortunately, once I copied my code base up to the test server (um, actually that was my production server, but that's another issue) I no longer had a working HTTP handler. In fact, the test server (prod) simply dropped a 404 error where it should have shown a PDF via my handler.

So, the first thing I was thinking was that my abstract class for the handler was not being reconized on the test/prod box. So, strong named it, recompiled, updated the reference, added it as an assembly to the web.config, and finally (just for good measure) installed it into the GAC. Guess what? None of these things worked. Still getting the stupid 404.

Searched on Google, found little help. Searched on Google again, still found little help. Finally, found this little gem on the ASP.Net Forums: http://forums.asp.net/t/1177230.aspx. In case they drop this thread in the future, let me give you the gist: IIS has a little area that no matter what your web.config says to do, it just won't care. So, I opened up IIS on my problem machine, went to the properties of my web site, clicked on the "Configuration" button on the Directory tab, and finally added a new entry for PDF to point it to the aspnet_isapi.dll like all the other extensions listed in that box.

SOLVED and my lovely handler now renders my dynamic PDF files like a champ on my test (prod) system as well as in my IDE.

Well, as my previous post lamented, I had to do some clever CSS/HTML/JavaScript work arounds in a solution I am building to prevent undesirable user interaction with my site. And, it worked pretty well. Unfortunately, the PDF Viewer control I was using in there didn't!

Actually, let me be fair, it worked, just not completely for what I needed it to do. I need the users to laod a PDF into the IFrame by selecting the document in the list box right? No problem, that works. Now, if the user then selects the Save button in the PDF window, it needs to actually show the PDF file name in the Save text box on that window. This is where the 3rd party viewer tool and I completely disagree on things. It wants to ONLY use the base file name in the SRC property of the IFrame. This would be just fine and dandy if I were using static PDF files, but I am most certainly NOT. I have to render these PDF files out from a Database (by the way, this system is WAY cool). So, what happens is that the Save As shows my ASPX page name in the Save As text box. Not good. I don't want users seeing my page names unless I put them on that page myself. And, again to be fair, it isn't the controls fault, it is actually the Adobe Reader.

The solution: throw away that 3rd party tool, write my own HttpHandler, register the handler to cover all PDF files, and then fake the SRC tag of the iframe to point to a bogus PDF file with the name I want to show in the Save As box.

This solution gets my issue resolved, but it also gives me the ability to do SO much more. Now I can do all kinds of cool stuff with parameters on a PDF file that wouldn't have really been possible without that HttpHandler. And the best part: those handlers are a breeze to write. I will share some of that later.

Yes, I think I might just be. I recently went out to Best Buy and grabbed a brand new Gateway laptop. That right there comes close to qualifying me as crazy. I just haven't been a huge fan of the cow for a long time, so it hurt a little to buy that one. But, it was the ONLY 64 bit, 4GB RAM, 250GB HD I could find for under $800. So, it's mine.

The second issue is it has a Red outer shell. I am a Georgia Tech guy, so this too hurts too much to discuss further.

Next crazy thing, it came preloaded with (gulp) Vista Home Premium 64 bit. I like the 64 bit. Not too sure about Vista and REALLY not sure about Home stuff and not being able to join domains. OK, so I actually like the Vista OS now. And I REALLY love the 64 bit and 4GB RAM on it. And, hate the home premuim. It doesn't support Virtual Server 2005.

And finally, the thing that really makes me crazy: I am now watching my brand new PC, now loaded with all of my great tools/data already (about 2 days worth of effort), attempt to "upgrade" itself to Vista Ultimate 64 bit. Yep, taking a perfectly working Vista machine and screwing with it. I am TOTALLY nuts. The stuff I do just to have Virtual systems. I really am crazy.

I have been a huge fan of IFrames for a long time, but have recently steered clear of them due to "cross-browser issues" with how they are rendered. Well, a solution I worked on recently basically required that I use an Object tag for PDF display inside of an IFrame - actually this is the way the tool worked, I would have done away with either the IFrame or the Object tag.

Anyway, I ended up with a simple list box that worked as a document selector. Select a document and on the post back the page loads your selected PDF into the Object tag in the IFrame. No problem. Well, one problem, that led to another.

If you get high energy users that want to click on three different documents before the page actually posts back you get big problems. The selector might indicate you should be viewing one document, but the PDF shows another.

So, this is easy to fix. Obviously, my first choice was to write a little javascript to disable the list control when the user selects a doc. Hmm, yeah, well that works so long as you don't actually want the value selected posted back to the server. The browser is so smart that it doesn't post back values from disabled controls. Ok, so I dropped to method 2 and add a little more JavaScript, some extra DIV tags and new CSS based on this from 4 Guys. Really cool and simple and mostly worked.

This got me almost there, but I suddenly had a really odd problem that I wasn't sure of what to do. I placed my new divs at z-index 999, but it was still showing behind the stupid IFrame/Object with my PDFs. I did some searching and found that most browsers render IFrames/Objects at the very top of the stack no matter what you do. I wrote JavaScript to try to override it; no luck. I just didn't have control.

The only thing I could do, and I did, was to actually set the iframe to visibility='hidden' when I show my new DIVs. What a pain. Why not just let me control where the IFrame is in the stack? Wouldn't that be much better?