04:44:58 PM
3HA0ZWHQ8
I think the behavior you *should see* (and that I do see with IE9 is: You should click the link and you should either start downloading (as Chrome/FireFox/Opera do) or it should prompt what you want to do with the file and then download it. In none of the cases does Excel open in the browser directly (other than clicking on the download after the fact).
You can use file-attachment header to force a specific filename and to force a download no matter what which is what I would recommend. Then there should be no ambiguity whether the browser needs to open the file or save it as a download.
http://www.west-wind.com/weblog/posts/2007/May/21/Downloading-a-File-with-a-Save-As-Dialog-in-ASPNET
Article is for ASP.NET but applies the same for Web Connection or any Web App for that matter.
Your suggestion assumes I'm starting with an XLS file already on disk.
DownloadFile() and TransmitFile() work with files from disk, but you cna use the same headers with values sent from a string. The advantage of TransmitFile and DownloadFile is that IIS serves these files rather than Web Connection which is much more efficient pushing the data back to the client while not tieing up your WC instances.
+++ Rick ---
Ok, I had a chance to look at this more closely. Your suggestion assumes I'm starting with an XLS file already on disk. In the past, it was possible to serve up standard table-based HTML, change the ContentType to "application/vnd.ms-excel" and the browser (IE, at least) would open Excel in the browser (or maybe it started Excel separately) and you could then save it as an XLS file to your disk. But that same code does not work in newer versions of IE, 8 and 9, I guess, and so I need a better way.
You can get it done now, but you get warnings. First I get this a dialog that says "What do you want to do with Analysis.xls?" and gives you Open, Save, Save As as your choices. So if you choose Open, you then get a dialog that says "The file you are trying to open, Analysis.xls, is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?" Then you get Yes and No choices.
Then it opens in Excel as Analysis.loc (notice that before it was saying xls and now loc as the extension, which is the scriptmap extension). Then when you try to do a Save As, it comes up with no file name and Web Page as the file type. I put the name as Analysis and change the file to Excel workbook and get Analysis.XLSX saved, but this is lots more work for the user than it used to be and I think it's due to security-related changes they've made in Windows or IE or both.
One of the advantages of doing it this way is that you get column headers from the HTML, which don't really exist in the underlying data that I used to build the HTML (except in that the field names are the column headers, but they are more readable in HTML, where they have std. names and not just a cryptic field name with no spaces).
The client wants it work like it used to, which was more seamless.
How are you serving the data?
This works for me with IE 9 (and IE 9 in Compatibility mode):
FUNCTION ServeExcelDocument lcFile = FILETOSTR("c:\saved\Travel2012.xls") Response.ContentType="application/vnd.ms-excel" Response.Write(lcFile) ENDFUNC
and just saves the file to disk. Most other browsers just download the file. If you want more control you can also use the FileAttachment header. Look into Response.DownloadFile or Response.TransmitFile.
If you want to open the Excel document in the browser I think you need to send back a different format - .csv should work to open in Excel if it's just data.
+++ Rick ---
Ping . . . any thoughts here? Is this built into WWWC and perhaps I'm missing it? It seems like tighter browser security . . .
West Wind Technologies
Making waves on the Web
from Maui, Hawaii
