Recently, I am conducting a Web project development, using the ASP.NET. The currently implemented report module, which is the output of the table by self-programming, and implements Chart generation through Microsoft's OWC technology. When the user reads the semi-finished products of this part, it is proposed to guide the report page to the functional requirements of Word or Excel.
After a multi-week query and discussion, the above requirements are proposed as the idea of implementing the following:
1. Save directly through the Java script, that is, saving the entire HTML document as DOC. The only advantage of this is simple, but the disadvantage is that the saved documentation includes many additional HTML tags (Head, Form, Hiden, etc.), and the pictures, etc. are downloaded to the Files directory, and the user needs to download it. The things are reintegrating and typing. This is not as good as possible to allow users to export Table and Chart, which is the second method.
2. Save the HTML label of the control you want to DOC or XLS via Response.Write. This method is now solved by technology, but the only thing that cannot be implemented is to output one or more Chart in a DOC (because the downloaded file is a certain encoding, and cannot be both word, also gif or other), Only separately separately. Separate exports are also easy to implement the export of XLS, because the picture cannot be exported to XLS!
3. Implement accurate control by calling "Microsoft Office Automation". Help implement encoding through the macro recordings in Word or Excel, and the documentation in the fixed format can also be implemented via the Template. However, there are many problems in this technology in the deepening discussion of its programming technology. Moreover, Microsoft does not recommend using this technology on the server, and does not provide technical support. These problems mainly include: reducing security levels to implement this technology; it is prone to deadlocks; need to be configured to achieve varying degrees of automation, and some configurations are also contradictory; etc. (see Microsoft Knowledge Base Article - 257757 "INFO: Precautions for automatically run Office")
4. Implement the client through "Microsoft Office Automation". This solution has certain requirements for the client, but also achieves interaction between B and C, there is a certain risk of technical difficulty and maintenance, and there is also certain risks;
5. Conformally, constructed such streams on the server side through Office2003 support, and then download to the client. This solution should not be too technically difficult to see now, and graphic can be in one document. But this solution is more troublesome, and the Office version used by the client must also be Office2003.
6. The user is currently Windows98 and Office2000 or Office97. It is necessary to support earlier versions to be implemented through the type of RTF format. But RTF is difficult to understand, and it is very troublesome to construct (for example, graphics must be segmented according to size).
This 6-middle program is uncomfortable to meet the needs of users, some of which have a risks of intensive, and some are complex. I don't know how to have any other ways? ? ?
