Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Problem with Open/Save Dialog Disappearing

Status
Not open for further replies.

jpaars

Programmer
Feb 24, 2004
7
US
Hi,

We have developed a relatively simple web application to distribute data and reports. The idea is to dynamically generate the reports at runtime then open the report in a new browser window. The process involves saving the generated report (either a pdf or excel file) to a folder on the server and then using a reponse.wirte line to run a javascript window.open to open the file. Specifically, this (in VB):

Response.Write("<script languare=javascript>window.open('reports/" & strFileName & "');")

where strFileName is (obviously) the name of the file that was generated and saved in the reports folder.

Here's what should happen. The user presses a button to generate a report. Assume pop-up blockers are taken care of and the appropriate browser plug-ins exist. Depending on the user's client-side settings, the report will either open unprompted in a new browser window or he will receive the open/save dialog.

So here's the problem. If a user presses a button for a report and his settings are such to receive the open/save dialog, the browser blinks/flashes as if the new window briefly opens but gets instantly shut down when the open/save dialog is hit. As if Internet Explorer is actually blocking it. Situations where reports open without hitting the open/save dialog (due to users' settings) work correctly.

Other potentially relavent information: It's ASP.NET 1.1 running on Windows Server 2003. Users reach it through a proxy server. The problem only occurs in IE6 and IE7. (IE5 and Firefox don't have problems.) But considering all the users are using IE6 or up, the problem is actually universal. Other pdf or excel files available on the same site are available through direct hyperlink and don't get "blocked" even when the open/save dialog is involved. Only those opened from the code (after button push) described above. If the generated report were to be opened (in the same code block) using a response.redirect instead and no window.open script (specifically: Response.Redirect("reports/" & strFileName)) there is no problem, even if the open/save dialog is involved. But obviously this doesn't open in a new window which we need to occur. The problem does not occur at all on the development machine or a staging site on the production server which is identical to the production site with the exception that it's not running through the proxy. In fact, accessing the production site without going through the proxy server (which can only be done internally) eliminated the problem.

I've already tried using the response.write/window.open to open a new (blank) aspx page with a response.redirect to the report in the page.load event to try to get around it. But the same thing (blinking/flashing/blocking) occurs.

So my best guess is that it's some combination of Internet Explorer and/or the proxy server and/or the script run in the code behind and/or the open/save dialog. Has anyone else seen or experienced anything like this? And does anybody have any ideas on a solution? I have searched all over but have found nothing so any help or even direction would be greatly appreciated.

Thanks, James
 
Firstly, if you want to register javascript don't use Response.Write. Use the RegisterClientScript or RegisterStartUpScript methods instead.

Secondly, why have a pop up window at all? Once you've written the file to disk, you can stream it to the client (using the Response.WriteFile method) and by changing the Response.ContentType to "octet/stream" it will prompt the user with the open/save dialog.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 
Thanks, ca8msm, for your input.

Admittedly, using RegisterClientScriptBlock or RegisterStartUpScript is probably a better way to go than a Response.Write. However, in the case of this problem with the open/save dialog not appearing, this doesn't make a difference. It still doesn't work. Basically, my thinking at this point is that somehow the fact that the proxy is involved is significant as checking the application without going through the proxy doesn't result in the same problem.

The Response.ContentType: octet/stream approach is one way to go and it actually doesn't experience the same problem. (We've looked at it before and might go back if we can't find another solution to our current problem.) The problem with it is that it always prompts with an "open/save" with no easy way for the user to opt out of that (i.e. no "always ask before opening file of this type" to uncheck). With some of our users running 70+ reports daily, this wouldn't be a very popular option. But maybe, if nothing else works...

Thanks again for your help. Any other thoughts (from anyone) would be appreciated.

Thanks, James
 
Admittedly, using RegisterClientScriptBlock or RegisterStartUpScript is probably a better way to go than a Response.Write. However, in the case of this problem with the open/save dialog not appearing, this doesn't make a difference.
Yes, you're probably correct but it's always best to make sure this isn't affecting anything by placing it in correct place in the HTML markup (which Response.Write doesn't do).

The Response.ContentType: octet/stream approach is one way to go and it actually doesn't experience the same problem. (We've looked at it before and might go back if we can't find another solution to our current problem.) The problem with it is that it always prompts with an "open/save" with no easy way for the user to opt out of that (i.e. no "always ask before opening file of this type" to uncheck). With some of our users running 70+ reports daily, this wouldn't be a very popular option. But maybe, if nothing else works...
I must have mis-understood you as I thought this was what you were maybe looking for. I'd try using the methods I suggested above and see what happens. If it still doesn't work, try pasting the resulting HTML markup from the page that should load and open the report. We can then see what is sent to the client and why it isn't working as expected.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top