Download Page as Attachment

Brian Paul

When a user clicks on a linkbutton on a page, i would like to render a printer-friendly version of the asp.net page and download it as an html attachment to the browser. The code below works great, with a few exceptions:

1) IE displays the FIle Download dialog box twice. (You have to click the Open button twice)
2) the encoding of the page is set to Western European (Windows) versus UTF-8.

#1 above is just a pain.
#2 above results in some wingding fonts to be displayed incorrectly in the page.

Anyone have suggestions on how to fix these problems or see any problems in the code? #2 is our highest priority.

CODE:

// this code is implemented in the Render method of the page
// when a user click the button, it sets renderAsAttachement = true, and adds the desired controls to be rendered
// to the propControlContainer Controls collection
protected override void Render(HtmlTextWriter writer)

{

if (renderAsAttachement)
{
Response.Clear();
Response.ContentEncoding = Encoding.UTF8;
Response.Charset = "utf-8";

Response.AppendHeader("Content-Disposition", String.Format("attachment;Filename=\"{0}\"", "Document1.htm"));
Response.ContentType = "text/html";

writer.WriteFullBeginTag("html");
writer.WriteLine();
writer.WriteFullBeginTag("head");
writer.WriteLine();
writer.Write(Globals.ColorScheme); // this renders a style sheet that is used by the page
writer.WriteLine();
writer.WriteEndTag("head");
writer.WriteLine();
writer.WriteFullBeginTag("body style=\"padding:5pt;\"");
writer.WriteLine();

propControlContainer.RenderControl(writer); // this is a parent control that renders all the child controls (in it's control collection)
// that are to be included in the "printer-friendly" version of the page

writer.WriteEndTag("body");
writer.WriteLine();
writer.WriteEndTag("html");
writer.WriteLine();

Response.End();
}
else
{
base.Render(writer);
}
}

Nov 18 '05 #1

MSFT

Hi Brian,

Thank you for posting in Microsoft Newsgroup. Regarding on the issue, I am
finding proper resource to assist you and we will update as soon as
posible.

Regards,

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 18 '05 #2

Brian Paul

thanks Luke!


"MSFT" <lukezhan@online.microsoft.com> wrote in message
news:1JFCm%23sxDHA.424@cpmsftngxa07.phx.gbl...[color=blue]
> Hi Brian,
>
> Thank you for posting in Microsoft Newsgroup. Regarding on the issue, I[/color]
am[color=blue]
> finding proper resource to assist you and we will update as soon as
> posible.
>
> Regards,
>
> Luke
> Microsoft Online Support
>
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>[/color]

Nov 18 '05 #3

MSFT

Hi Brian Paul,


Thank you for using Microsoft Newsgroup service. Based on your description,
you had a aspx page to provide a certain format html document for the user
to open in browsr or download to client. The html document has some
"printer-friendly" data( are they all unicode data?). Also, you set the
page's Header as
Response.AppendHeader("Content-Disposition",
String.Format("attachment;Filename=\"{0}\"", "Document1.htm")); to force
the download dialog to popup and set the charset as "UTF-8"

However, when you run the page and fire the download operation, you
encountered two problems:
1. the download dialog popup twice
2. some of the html document's data doesn't display correctly

Please correct me if my understanding or your problem is not quite accurate.

As for the above two problems I've done some tested on them. I also met the
first problem, it is a bit strange why the dialog popup twice. I'll do some
further research on it and I also find a way to workaround the problem:
Just using another page to render the document output which will be
downloaded or opened. Add the "render" method in this page.

In the original page, just use a simple hyperlink which point to document
page, such as
<a href="showdoc.aspx">open document</a>

the "showdoc.aspx" is just the page which has the "render? method to
generate the "printer-friendly data and show download dialog.
Thus, the pop dialog won't popup twice.


As for the second problem. You said that " the encoding of the page is set
to Western European (Windows) versus UTF-8" and some "wingding fonts "
doesn't display correctly. Do you means that when the document is opended
in the browser, the Encoding of the browser is set as "western European"
rather than "UTF-8"? And if you change the browser's view->encoding to
"UTF-8", does those "wingding fonts " display correctly?
If it can display correctly when you set the browser's view->encoding as
"UTF-8", the problem is caused by the client browser's default encoding
setting. Since the default encoding of the client browser is set as
"western European", when you open a certain page in the browser, it will
always first display using the default setting. This feature is not set via
the serverside code.

If the "wingding fonts" still can't display correctly when you chang the
browsesr's view->encoding to "UTF-8", I think the problem is likely due to
the "wingding fonts" which can't display well in UTF-8. Thus, would you
please provide some of the "wingding fonts" which can't display well so
that I can do further research on them?


Please try out the preceding suggestion to see whether it helps. Also if
you have any questions on it, please feel free to let me know.


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 18 '05 #4

Brian Paul

Hi Steven,

Thanks very much for your time on this. I sure appreciate it your support.
You found the problem to #2. See my responses in CAPS inline below:

thanks again!!!

"MSFT" <v-schang@online.microsoft.com> wrote in message
news:3YoG3bFyDHA.3532@cpmsftngxa07.phx.gbl...[color=blue]
> Hi Brian Paul,
>
>
> Thank you for using Microsoft Newsgroup service. Based on your[/color]
description,[color=blue]
> you had a aspx page to provide a certain format html document for the user
> to open in browsr or download to client. The html document has some
> "printer-friendly" data( are they all unicode data?). Also, you set the
> page's Header as
> Response.AppendHeader("Content-Disposition",
> String.Format("attachment;Filename=\"{0}\"", "Document1.htm")); to force
> the download dialog to popup and set the charset as "UTF-8"
>
> However, when you run the page and fire the download operation, you
> encountered two problems:
> 1. the download dialog popup twice
> 2. some of the html document's data doesn't display correctly
>
> Please correct me if my understanding or your problem is not quite[/color]
accurate.[color=blue]
>
> As for the above two problems I've done some tested on them. I also met[/color]
the[color=blue]
> first problem, it is a bit strange why the dialog popup twice. I'll do[/color]
some[color=blue]
> further research on it and I also find a way to workaround the problem:
> Just using another page to render the document output which will be
> downloaded or opened. Add the "render" method in this page.
>
> In the original page, just use a simple hyperlink which point to document
> page, such as
> <a href="showdoc.aspx">open document</a>
>
> the "showdoc.aspx" is just the page which has the "render? method to
> generate the "printer-friendly data and show download dialog.
> Thus, the pop dialog won't popup twice.
>[/color]
THANKS FOR THE SUGGESTION, HOWEVER, IT'S A LOT MORE WORK THAN MY CURRENT
IMPLEMENTATION.

HERE'S WHY:

IN MOST CASES DATAGRIDS ARE THE CONTROLS TO BE RENDERED ON EACH PAGE. THE
PAGE ALLOWS FILTERS TO BE SET FOR THE DATAGRID. YOU CAN ALSO SORT THE DATA
BY CLICKING ON THE HEADER COLUMN WITHIN EACH DATAGRID.

USING A SEPERATE PAGE REQUIRES ME TO PASS ALL THE FILTER AND SORT PARAMS TO
THE 2ND PAGE AND RE-DATABIND ALL THE GRID(S) (REQUIRING ANOTHER ROUND TRIP
TO THE DB).

USING THE SAME PAGE IS MUST SIMPLER AND EFFICIENT. I DON'T HAVE TO SEND ALL
THE PAGE PARAMS, AND I DON'T EVEN HAVE TO RE-DATABIND THE GRIDS. I JUST ADD
THE GRID TO THE RENDER FUNCTION OF THE PARENT PAGE AND THE GRID(S) ARE
RENDERED BASED ON THEIR CURRENT VIEWSTATE.

IF AT ALL POSSIBLE, I WOULD LIKE TO STAY WITH THE SINGLE PAGE
IMPLEMENTATION.

-----
AFTER MORE INITIAL TESTING I HAVE FOUND THAT SOME VERSIONS OF IE6 ON WINXP
DON'T PROMPT TWO DIALOGS. THE IE VERSIONS ARE THE SAME, BUT ONE HAS MORE
UPDATES:

THIS ONE PROMPTS TWICE:
IE VERSION ON WINXP: 6.0.2800.1106.XPSP2.030422-1633
UPDATES: SP1, Q328970, Q324929, Q810847, Q813951, Q813489, Q330994, Q818529,
Q822925, Q828750, 824145

THIS ONE PROMPTS ONCE:
IE VERSION ON WINXP: 6.0.2800.1106.XPSP2.030422-1633
UPDATES: SP1, Q810847, Q813951, Q813489, Q330994, Q818529, Q822925, Q828750,
824145
IT DOES NOT INCLUDE: Q328970, Q324929 ....SO MAYBE IT HAS SOMETHING TO DO
WITH ONE OF THESE UDPATES.[color=blue]
>
> As for the second problem. You said that " the encoding of the page is set
> to Western European (Windows) versus UTF-8" and some "wingding fonts "
> doesn't display correctly. Do you means that when the document is opended
> in the browser, the Encoding of the browser is set as "western European"
> rather than "UTF-8"?[/color]

YES, THAT IS CORRECT.

And if you change the browser's view->encoding to[color=blue]
> "UTF-8", does those "wingding fonts " display correctly?[/color]

YES, THAT FIXED IT!!!! ONE QUESTION THOUGH, OUT OF THE BOX, WHAT IS IE'S
DEFAULT ENCODING? I DON'T RECALL CHANGING THIS SETTING ON ANY OF OUR TEST
MACHINES.
[color=blue]
> If it can display correctly when you set the browser's view->encoding as
> "UTF-8", the problem is caused by the client browser's default encoding
> setting. Since the default encoding of the client browser is set as
> "western European", when you open a certain page in the browser, it will
> always first display using the default setting. This feature is not set[/color]
via[color=blue]
> the serverside code.
>
> If the "wingding fonts" still can't display correctly when you chang the
> browsesr's view->encoding to "UTF-8", I think the problem is likely due to
> the "wingding fonts" which can't display well in UTF-8. Thus, would you
> please provide some of the "wingding fonts" which can't display well so
> that I can do further research on them?
>
>
> Please try out the preceding suggestion to see whether it helps. Also if
> you have any questions on it, please feel free to let me know.
>
>
> Steven Cheng
> Microsoft Online Support
>
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>[/color]

Nov 18 '05 #5

Brian Paul

Hi Steven,

After doing more testing with issue #2 below i've found that when the
document opens as an attachment in the new window, the encoding always
defaults to Western European (Windows) -- even after the default setting in
IE under View/Encoding is set to UTF-8. In the new window once the document
has opened, if i change the encoding to UTF-8, the Wingding font (a checkbox
symbol) is displayed correctly. However, this is a pain to require the
user's to do this each time. Is there a way to ensure the new window opens
using UTF-8?

thanks,
Brian

"Brian Paul" <brianp@ekyros.com> wrote in message
news:OfQxUMKyDHA.1680@TK2MSFTNGP12.phx.gbl...[color=blue]
> Hi Steven,
>
> Thanks very much for your time on this. I sure appreciate it your[/color]
support.[color=blue]
> You found the problem to #2. See my responses in CAPS inline below:
>
> thanks again!!!
>
> "MSFT" <v-schang@online.microsoft.com> wrote in message
> news:3YoG3bFyDHA.3532@cpmsftngxa07.phx.gbl...[color=green]
> > Hi Brian Paul,
> >
> >
> > Thank you for using Microsoft Newsgroup service. Based on your[/color]
> description,[color=green]
> > you had a aspx page to provide a certain format html document for the[/color][/color]
user[color=blue][color=green]
> > to open in browsr or download to client. The html document has some
> > "printer-friendly" data( are they all unicode data?). Also, you set the
> > page's Header as
> > Response.AppendHeader("Content-Disposition",
> > String.Format("attachment;Filename=\"{0}\"", "Document1.htm")); to force
> > the download dialog to popup and set the charset as "UTF-8"
> >
> > However, when you run the page and fire the download operation, you
> > encountered two problems:
> > 1. the download dialog popup twice
> > 2. some of the html document's data doesn't display correctly
> >
> > Please correct me if my understanding or your problem is not quite[/color]
> accurate.[color=green]
> >
> > As for the above two problems I've done some tested on them. I also met[/color]
> the[color=green]
> > first problem, it is a bit strange why the dialog popup twice. I'll do[/color]
> some[color=green]
> > further research on it and I also find a way to workaround the problem:
> > Just using another page to render the document output which will be
> > downloaded or opened. Add the "render" method in this page.
> >
> > In the original page, just use a simple hyperlink which point to[/color][/color]
document[color=blue][color=green]
> > page, such as
> > <a href="showdoc.aspx">open document</a>
> >
> > the "showdoc.aspx" is just the page which has the "render? method to
> > generate the "printer-friendly data and show download dialog.
> > Thus, the pop dialog won't popup twice.
> >[/color]
> THANKS FOR THE SUGGESTION, HOWEVER, IT'S A LOT MORE WORK THAN MY CURRENT
> IMPLEMENTATION.
>
> HERE'S WHY:
>
> IN MOST CASES DATAGRIDS ARE THE CONTROLS TO BE RENDERED ON EACH PAGE. THE
> PAGE ALLOWS FILTERS TO BE SET FOR THE DATAGRID. YOU CAN ALSO SORT THE[/color]
DATA[color=blue]
> BY CLICKING ON THE HEADER COLUMN WITHIN EACH DATAGRID.
>
> USING A SEPERATE PAGE REQUIRES ME TO PASS ALL THE FILTER AND SORT PARAMS[/color]
TO[color=blue]
> THE 2ND PAGE AND RE-DATABIND ALL THE GRID(S) (REQUIRING ANOTHER ROUND TRIP
> TO THE DB).
>
> USING THE SAME PAGE IS MUST SIMPLER AND EFFICIENT. I DON'T HAVE TO SEND[/color]
ALL[color=blue]
> THE PAGE PARAMS, AND I DON'T EVEN HAVE TO RE-DATABIND THE GRIDS. I JUST[/color]
ADD[color=blue]
> THE GRID TO THE RENDER FUNCTION OF THE PARENT PAGE AND THE GRID(S) ARE
> RENDERED BASED ON THEIR CURRENT VIEWSTATE.
>
> IF AT ALL POSSIBLE, I WOULD LIKE TO STAY WITH THE SINGLE PAGE
> IMPLEMENTATION.
>
> -----
> AFTER MORE INITIAL TESTING I HAVE FOUND THAT SOME VERSIONS OF IE6 ON WINXP
> DON'T PROMPT TWO DIALOGS. THE IE VERSIONS ARE THE SAME, BUT ONE HAS MORE
> UPDATES:
>
> THIS ONE PROMPTS TWICE:
> IE VERSION ON WINXP: 6.0.2800.1106.XPSP2.030422-1633
> UPDATES: SP1, Q328970, Q324929, Q810847, Q813951, Q813489, Q330994,[/color]
Q818529,[color=blue]
> Q822925, Q828750, 824145
>
> THIS ONE PROMPTS ONCE:
> IE VERSION ON WINXP: 6.0.2800.1106.XPSP2.030422-1633
> UPDATES: SP1, Q810847, Q813951, Q813489, Q330994, Q818529, Q822925,[/color]
Q828750,[color=blue]
> 824145
> IT DOES NOT INCLUDE: Q328970, Q324929 ....SO MAYBE IT HAS SOMETHING TO DO
> WITH ONE OF THESE UDPATES.[color=green]
> >
> > As for the second problem. You said that " the encoding of the page is[/color][/color]
set[color=blue][color=green]
> > to Western European (Windows) versus UTF-8" and some "wingding fonts "
> > doesn't display correctly. Do you means that when the document is[/color][/color]
opended[color=blue][color=green]
> > in the browser, the Encoding of the browser is set as "western European"
> > rather than "UTF-8"?[/color]
>
> YES, THAT IS CORRECT.
>
> And if you change the browser's view->encoding to[color=green]
> > "UTF-8", does those "wingding fonts " display correctly?[/color]
>
> YES, THAT FIXED IT!!!! ONE QUESTION THOUGH, OUT OF THE BOX, WHAT IS IE'S
> DEFAULT ENCODING? I DON'T RECALL CHANGING THIS SETTING ON ANY OF OUR TEST
> MACHINES.
>[color=green]
> > If it can display correctly when you set the browser's view->encoding as
> > "UTF-8", the problem is caused by the client browser's default encoding
> > setting. Since the default encoding of the client browser is set as
> > "western European", when you open a certain page in the browser, it will
> > always first display using the default setting. This feature is not set[/color]
> via[color=green]
> > the serverside code.
> >
> > If the "wingding fonts" still can't display correctly when you chang the
> > browsesr's view->encoding to "UTF-8", I think the problem is likely due[/color][/color]
to[color=blue][color=green]
> > the "wingding fonts" which can't display well in UTF-8. Thus, would you
> > please provide some of the "wingding fonts" which can't display well so
> > that I can do further research on them?
> >
> >
> > Please try out the preceding suggestion to see whether it helps. Also if
> > you have any questions on it, please feel free to let me know.
> >
> >
> > Steven Cheng
> > Microsoft Online Support
> >
> > Get Secure! www.microsoft.com/security
> > (This posting is provided "AS IS", with no warranties, and confers no
> > rights.)
> >[/color]
>
>[/color]

Nov 18 '05 #6

MSFT

Hi Brian ,


Thank you for the prompt response. As the problem you descirbed in the
response, I think you can try this:

In IE, click View, point to Encoding. Uncheck "Auto Select" and select
"UTF-8"

Please do uncheck the "Auto Select", then, when you open IE in other
document, the Encoding will focus on "UTF-8"

However, since such operations are on client side. So if the user used to
set the IE's encoding as other options(not UTF-8). He still should to
change it manually. Also, I've reviewed some references on IE'S setting,
the algorism IE uses to set encoding for a page is below:



1. If the web page has set the language encoding to use, IE will use the
encodin
g.

2. If the web page has not set the language encoding to use and IE uses
Auto-Sel
ect, IE will determine which one is the best encoding.

3. If the web page has not set the language encoding to use and IE doesn¡¯t
uses
Auto-Select, IE will use the default encoding. The fault encoding is at
[HKEY_C
URRENT_USER\Software\Microsoft\Internet Explorer\International]
Defalt_CodePage.


Yes, generally, wo may try editing the registry via script(such as change
IE'S print setting). However, for the encoding setting, IE has its own
algorism to decide the encoding method, customer cannot use her own ActiveX
control(also script) to change it.

If you have any questions on it, please feel free to let me know.


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 18 '05 #7

Brian Paul

Here's what i've come up with which fixes both issues:

1) Render the controls to a new HtmlTextWriter
2) convert the rendered control text to a byte array
3) store it to a image type in a db.
4) then Response.Redirect() to a printerfriendly.aspx and pass the record id
of the rendered content from step 3.

by persisting the content to the db and redirecting to a second page:

1) IE does not prompt the open dialog twice.
2) the encoding seems to work correctly.

I haven't had a chance to test for performance. but we are using a pretty
hefty (dual proc/gobs of ram) db server. So i'm hoping performance will be
ok.


"MSFT" <v-schang@online.microsoft.com> wrote in message
news:qG1z2ERyDHA.2604@cpmsftngxa07.phx.gbl...[color=blue]
>
>
> Hi Brian ,
>
>
> Thank you for the prompt response. As the problem you descirbed in the
> response, I think you can try this:
>
> In IE, click View, point to Encoding. Uncheck "Auto Select" and select
> "UTF-8"
>
> Please do uncheck the "Auto Select", then, when you open IE in other
> document, the Encoding will focus on "UTF-8"
>
> However, since such operations are on client side. So if the user used to
> set the IE's encoding as other options(not UTF-8). He still should to
> change it manually. Also, I've reviewed some references on IE'S setting,
> the algorism IE uses to set encoding for a page is below:
>
>
>
> 1. If the web page has set the language encoding to use, IE will use the
> encodin
> g.
>
> 2. If the web page has not set the language encoding to use and IE uses
> Auto-Sel
> ect, IE will determine which one is the best encoding.
>
> 3. If the web page has not set the language encoding to use and IE[/color]
doesn¡¯t[color=blue]
> uses
> Auto-Select, IE will use the default encoding. The fault encoding is at
> [HKEY_C
> URRENT_USER\Software\Microsoft\Internet Explorer\International]
> Defalt_CodePage.
>
>
> Yes, generally, wo may try editing the registry via script(such as change
> IE'S print setting). However, for the encoding setting, IE has its own
> algorism to decide the encoding method, customer cannot use her own[/color]
ActiveX[color=blue]
> control(also script) to change it.
>
> If you have any questions on it, please feel free to let me know.
>
>
> Steven Cheng
> Microsoft Online Support
>
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>
>
>[/color]

Nov 18 '05 #8