You may want to look at using Spreadsheet::WriteExcel for creating the Excel file.

You won't be able to automatically download the Excel file to a specific location unless you use some sort of Applet/ActiveX component, which every user would need to install. Since it is unlikely you will be able to force such a regime upon users, you may be better just including instructions for downloading the Excel file.

Martin

--
John.

I've done something similar. What I did was this: I had a page with a 'download' button. Clicking that button invoked a CGI script - but the script set its MIME type to something other that 'text/html' in the header. On most browsers, this makes you get a dialog asking if you want to 'save' or 'run' (assuming there's an associated application for that particular file type.). In my case, I was creating a .csv file (comma serparated value), and I had excel defined to be the default app for .csv files, so when I clicked 'download' I could either save the .csv file on my local hard disk, or I could open the file directly in excel (once inside excel, you can always choose 'save as' if you want to save).

Hi scorpio17,

I also want to do something similar. What I want to have is: a page with a 'download' button. Upon clicking the button it will prompt you for save or open. Once you click on either save or open, it should write all the outputs in an excel file and save it to the location you have mentioned.

Please help me on this further.

Thanks, sir_com

This site is not a script writing service. This site is about helping each other with concrete programming problems. You haven't shown any code and haven't told us where your problem with the code you have actually lies.

Maybe you want to just use Querylet and/or Querylet::CGI.

Alternatively, you want to use Spreadsheet::WriteExcel.

But we won't write complete programs for you.

I've seen cases in the past where the Excel file to download was actually a CSV. This is much easier to generate than a real Excel file.

I'd say CSV is probably the best in terms of portability.  Excel reads these just fine.

 

+1 to you sir.

I'd say CSV is probably the best in terms of portability.

The files produced by Spreadsheet::WriteExcel are just as portable as CSV files. In addition they can provide features that CSV files cannot such as multiple worksheets, formatting, merged ranges, printing options and embedded images to name a few.

--
John.

I've seen cases in the past where the Excel file to download was actually a CSV. This is much easier to generate than a real Excel file.

It can actually be quite tricky to generate a CSV file that Excel will read. Especially if your data contains commas, quotes, newlines or other significant entities.

Normally it isn't something that should be attempted without a module such as Text::CSV_XS. In which case it is just as easy to use Spreadsheet::WriteExcel and produce a real Excel file.

--
John.

For a simple numeric table, CSV is not particularly hard (no escapes or quotes needed).

In the general case, I agree, a CSV module would be preferred. I vaguely remember problems getting Spreadsheet::WriteExcel installed on a system a few years ago. Which is why I suggested an alternate approach.

G. Wade

Why use open source to export to proprietary closed format?

Because the client demands it?

MS clearly dominates the office suite market since at least Win95, and millons of people are trained to use MS Office. They don't say or think spreadsheet, they say and think Excel. They don't say or think presentation software, they say and think Powerpoint. Not database, Access (or sometimes Excel). Not text processor, Word. Not mail user agent or groupware, Outlook.

I don't like this situation either, but there is a difference between consulting and preaching. Good consulting ensures the next job at the client, preaching can cost you the current and all following jobs.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

I can understand from my post that it would appear that I preach and it stops there.

I also deal with clients. Mostly groups of people, not individuals.

In this specific case, the truth is, it can't be done. Sure, it *looks* like it's being done- but there's no way to truly guarantee it. The only people that could really guarantee that the output is correct are the people with access to 100% of whatever a excel file is *supposed* to be.
And unless you're working for M$, you cannot honestly assure the client that not only does it *look* like it works, but it *works*.

Dealing with weird transformations of proprietary format and junk like this- opens your company/institution to possible danger.

There is are a couple of ways to do this properly. Either manually via the gui that M$ provides- or via some M$ development java or c++ dev lib they provide (they must have something).

Anything else, and you can't guarantee your client that you are outputting true xxx files.

Now, I work with proprietary format junk from time to time. But I do not output proprietary format. I can guarantee the client that the output is what it is.
It doesn't just look like it works, it works.

When faced with situations like these, I've found ways around it- to still solve the problem. It's been good so far.

If users assimilate 'Word' with a text file, it's the fault of people like you and me that just want to take a paycheck and not educate users.

put an end to word attachments