Practical ASP.NET

Supporting a Printer-Friendly Page Button (Part I)

Peter investigates three solutions for getting junk off your page when the user wants to print a copy.

Often, when users want to print a copy of your Web page, there's all sorts of stuff on the page that they don't want: the company logo, the menu, and other 'site-support' paraphernalia. A button that lets the user get a "printer-friendly" version of your page could just redirect the user to a new page without "the junk". However, that would require you to maintain two versions of the same page, one with a Master Page and one without -- an extra maintenance burden. And as a result, you'd only offer this option on a limited number of pages.

In most cases the stuff that the user wants to omit is all on your Master Page. In fact, with that in mind, the first step in supporting a PrinterFriendly button on every page on your site is to design your site with all your 'site support' controls on your Master Pages, while your WebForms (your content) have just the information that your user wants. After that, you have three potential solutions you can implement. I'll discuss one this week and the other two next week.


The Master Page Solution
My first solution is to create a second Master Page that has the minimum number of controls on it that you can get away with (e.g. remove the menu -- the user can click on the browser's back button to return to a full-featured page -- but leave the copyright and company name). This Master Page also reduces what controls are left on it and rearranges all the controls to maximize output for printing. Now, the trick is to swap that Master Page in when the user clicks on your PrinterFriendly button.

Changing Master Pages at runtime is complicated by the life-cycle of a Web Page. You can change your Master Page at runtime but you must do it in the Page's PreInit event. You'll have to "restart" the page after responding to the Click event of the PrinterFriendly button. You can do that by using Server.Transfer to the current page, whose name I'll retrieve through the Page's AppRelativePath property.

So, after dragging a button onto your content page, I drop this code in the button's Click event. This code transfers control back to the current page (refiring the PreInit event) and passes a flag in the QueryString:

Protected Sub PrinterFriendly_Click(ByVal sender As Object, _
      ByVal e As System.EventArgs) Handles PrinterButton.Click
        Me.Server.Transfer(Me.AppRelativeVirtualPath & "?PrinterFriendly=True")
End Sub
    

In the Page's PreInit event, I check the QueryString for my PrinterFriendly flag and, if it's present, load the "PrinterFriendly" version of the Master Page:

Protected Sub Page_PreInit(ByVal sender As Object, _
                   ByVal e As System.EventArgs) Handles Me.PreInit
        If Me.Request.QueryString("PrinterFriendly") = "True" Then
            Me.MasterPageFile = "PrinterFriendly.master"
        End If
End Sub

If you want to offer the printer-friendly option on every page, the first step is to put the PrinterFriendly button in your Master Page and put this code in its Click event:

Protected Sub PrinterFriendly_Click(ByVal sender As Object, _
      ByVal e As System.EventArgs) Handles PrinterFriendly.Click
        Me.Server.Transfer(Me.Page.AppRelativeVirtualPath & "?PrinterFriendly=True")
End Sub

You'll need to put the PreInit code in some Class file that inherits from System.Web.UI.Page and have your content pages inherit from this Class rather than directly inheriting from System.Web.UI.Page.

No Free Lunch
Having a second Master Page does impose a maintenance burden. You'll need to keep both Master Pages synchronized -- they both must have a similar number of ContentPlaceHolders with the same names, at the very least. However, the Master Page solution is the most flexible of the three that I'll propose because it lets you add content to the printer friendly page if you need it.

There is a problem with this solution if you access your Master Page from your content page with code like this:

Dim mp As MyMaster
mp = CType(Me.Master, NorthwindMaster)

To handle this problem, you'll need to replace that code with code that checks which Master Page you have loaded before casting the Master property. Note that if you are using the MasterType tag in your Content page, you will have to remove it:

Dim mp As MyMaster
Dim pf As PrinterFriendly
If Me.Master.GetType.Name = "mymaster_master" Then
            mp = CType(Me.Master, MyMaster)
Else
            pf = CType(Me.Master, PrinterFriendly)
End If

Next week I'll discuss two alternative approaches for making your Web pages printer-friendly at the click of a button.


About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in ASP.NET development with expertise in SOA, XML, database, and user interface design. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on technical writing can be found at rtfmphvis.blogspot.com.

Reader Comments:

Sat, Jan 23, 2010 ravinath sri lanka

sir , i want study VB from E mail. Please send me basic of VB . tks

Fri, Jan 22, 2010 Peter Vogel Canada

Craig: And if you've got design/UI guys with that expertise they can even build the stylesheet instead of the ASP.NET guy (i.e. me) having to do it!

Thu, Jan 21, 2010 Craig

Of course the solution is stylesheets. Plus, swapping out imagery can easily be done - have sections that are "display:none" in your normal stylesheet, then "display: block" (or whatever you need) in your print stylesheet. Re-rendering the page for the sake of producing a print-friendly stylesheet sounds an awful waste of resources. Not to mention management thereof longer term. In most situations, our print stylesheet simply says "hide the navigation (top/bottom), remote extranous backgrounds, show some print-specific data". It's normally about 1KB. It also means your design/UI guys can be completely in control of the aesthetics.

Tue, Jan 19, 2010

alert("Boo!");

Mon, Jan 18, 2010 Eric Jönköping, Sweden

You can also have your masterpages inherit from a common class that in turn inherits from the MastePage class. This way you can implement all your common masterpage code/interfaces in the new master class and just cast to that instead.

Wed, Oct 14, 2009 Peter Vogel Canada

Glad you found the column useful. Make sure that you also read the second part which addresses solutions that don't involve creating a second Master Page (and one that is driven by client-side script). These are also very "ASP.NET"is solution: If you're willing to get in the world of CSS, check out the web page that I recommend in one of the comments on that column.

Thu, Oct 8, 2009 Paul Chippendale Brisbane, Australia

Thanks, very useful -- always wondered how it was done

Fri, Oct 2, 2009 Peter Vogel Canada

You're right--next week's column will cover using a stylesheet. However, using a Master Page lets you add content to your "printer friendly" page that doesn't make sense on your web page--a different company logo, for instance, for your your paper version.

Thu, Oct 1, 2009 T A MN, USA

I hope one of the next two options involves a print stylesheet. This almost always works for the development I've done.

Thu, Oct 1, 2009 Mike

I agree with Tom. There's only only sensible solution to this issue (a solution that has existed for many years) - a print optimised stylesheet.

Thu, Oct 1, 2009 Tom Philo Portland, Oregon

Should not this tie back into stylesheets so that the you can leverage this - avoiding the multiple master page aspect - that is designed to be used to print web pages devoid of the extra fluff as well as the print friendly button?

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above