So, I've got an ASP.NET page, call it foo.aspx, that pumps out an ActiveReport named rptFoo like this:
Dim m_stream As New System.IO.MemoryStreamDim rpt As New rptFoorpt.DataSource = dsReportrpt.DataMember = "Report"rpt.Run()Me.PdfExport1.Export(rpt.Document, m_stream)m_stream.Position = 0Response.ContentType = "application/pdf"Response.AddHeader("Content-Length", m_stream.Length.ToString())Response.AddHeader("Content-Disposition", "inline; filename=Foo.pdf")Response.BinaryWrite(m_stream.ToArray())Response.End()
Now, this all works great, and pulls up the Acrobat document inside the browser. The problem comes when the user clicks on the Acrobat E-mail button, and sends the document. Instead of "Foo.pdf" the attachment (which is the valid PDF) comes across as "foo.aspx".So, how do I fool Acrobat into thinking that the file it's dealing with is really foo.pdf when it comes time to send e-mail?
Hello,Firstly, the filename that Acrobat uses as the email attachment is really outside the realm of ActiveReports and is up to the Acrobat application.Secondly, there is work-around, change line of codeResponse.AddHeader("Content-Disposition", "inline; filename=Foo.pdf")toResponse.AddHeader("Content-Disposition", "attachment; filename=Foo.pdf")
Well, Acrobat presumably is getting the name based on something that the Web server is sending - but it looks like it may just be the original page name out of the HTTP request, which is annoying. I suppose I could rename the aspx page to Foo.pdf and then bind *.pdf to the ASP.NET processor in IIS, but ick.I've tried attachment rather than inline, and it avoids this problem but brings up two others: (1) opens in a new window [yes, I know that's the whole point of a windowed environment, but this is an application for a naive bunch of unders] (2) You get the big scary "Danger Will Robinson!" dialog box asking them whether they want to download the attachment.Bah.