we use an application that has an "export to excel" feature that doesn't work on PC's that done have outlook express installed.
i know, you're thinking "WTF does outlook express have to do with excel files?"
i asked the same thing, and here's what i found:
the file being generated is actually one of those Microsoft Single File Web Pages (.mht) and NOT an excel file
you need to have outlook express installed to actually view a .mht file.
i've explained to their support people that just because you can slap a .xls on a file and excel will open it does not mean its an excel file, and does not mean that this is the right way to do it.
how would you explain that this is not proper?
Many people (especially managers) confuse Excel files with reporting files. In my opinion, a file is only qualified as an Excel file if it meets all of these conditions:
Is a spreadsheet formatted in one of the many Microsoft Excel formats.
Can be opened in the most recent version of Microsoft Excel.
Is editable in Microsoft Excel.
In your case, I'm guessing only condition #3 is met, so it's no Excel file. But your support people may still call it a reporting file.
If a clean Windows image with only Excel installed can't open it, then it isn't in Excel format. Period.
If a Windows machine with Outlook Express, but without Excel can open it (if you change the extension) then it can't be an Excel file. I'd combine that with Ignacio's suggestion for a slam-dunk.
Plus, surely if it's MHT, then you can't actually do spreadsheet operations on it? Or am I misunderstanding how it works?
I don't think your statements are correct. Excel (2007) has import and export filters for single-file HTML documents (.mht) even if there is no Outlook Express installed. However, this is not a native format and worksheet features such as formulas cannot be retained (see http://office.microsoft.com/en-us/excel/HP100141051033.aspx#7)
So what you should make clear to your customers is that there is a difference between an applications native file format and a format which isn't designed to contain spreadsheet functionality and that is only supported via an import/export filter.
Related
We have a ms-excel xlsx file stored in SharePoint. This file can be edited in two ways: directly in SharePoint or through ms-access acting as a front-end of the xlsx file (as an external linked table). We want the xlsx file to be edited while the ms-access database is open.
While ms-access is open, the xlsx file appears as read-only. We want programmatically disable the read-only state, so that other people could edit the xlsx file while ms-access is open and, also, enable read-only again when necessary.
I think that the only way to get this is by sharing the xlsx file. My question is as follows:
I don't know whether the best way to share the xlsx file is using co-authoring or using the standard ms-excel sharing. We tried to do it manually using co-authoring, but the xlsx file could not be edited through ms-access.
If we manage to edit the xlsx file through ms-access, then, is it possible to change the shared status programmatically while ms-access is open throug VBA, .NET, VSTO, MS-Javascript API or any other language? I have searched in Google, but I have found nothing but some .NET library for ms-word (Microsoft.Office.Interop.Word.CoAuthoring), but, curiously, not for ms-excel and, as the great wise Confucius said, "if you search something in Google for more than three hours and you don't find it, this means that it doesn't exist".
But maybe someone has had this same odd problem and could help us.
Thanks in advance.
You can't. The first application to open the file will "hold" it, and the next will either could open it as read-only or not at all.
You may be able to let Access open the Excel file, import the data to a table, and then close the file. If the file already is opened in Excel, it may fail, and that you must, of course, take care of.
Another option could be to have a function in Excel that exports the data to another workbook, and then let Access read this.
We're working on a Excel Add-In in C# .Net 4.
One of the requirements is to update a worksheet with results of some processing.
The issue is, we need to do this both while the Excel file is open (with the Add-In), and also in batch (while the file is closed).
We have a SpreadsheetGear licence already to generate Excel files.
Is it possible to modify an XLS file whilst it is open in Excel, using SpreadsheetGear?
Or must we have two sets of code to generate the same information? One using Excel Interop for open files, and one using SpreadsheetGear on closed files?
Got a direct response from SpreadsheetGear.
SpreadsheetGear runs on a totally separate process from Excel and has
no way to access their runtime and/or currently opened workbooks—our
product was built from the ground up using the .NET Framework
libraries and has absolutely no dependencies from Excel. The only way
to access files like you require would be to first save them to disk
from Excel and then open them with SpreadsheetGear.
So it looks as if we'll have to implement two sets of code to do the same thing.
Thinking that to solve a problem I've got this is the fastest solution:
Generate a custom CSV file on the file (this is already done via Perl).
Have a XLS document opened via commandline via a scripting language (clients already got a few Perl scripts running in this pipeline.)
Write VBA or record a macro that executes the following OnLoad:
Imports a the data from the CSV file into the report template,
Print the file via PDF driver to fixed location using data in the CSV to name the file.
Closes the XLS file.
So, is this possible via Excel macros, if not is it possible via VBA -- thanks!
NOTE: Appears I've got to have a copy of MS Office anyway, so this is much faster to get going than using Visual Studio Tools for Office (VSTO). The report template is going to be on a server, and this way the end user can build as many reports as they like, "test" by printing a PDF using a demo CSV file, and import/embed the marco or VBA when they're done. I'd looked in Jasper Reports, but the end user is putting ad-hoc static text and groupings all over the report and I figure this way they can build reports how ever they want and then automate them. Both of these questions by me and the resulting comments/feedback are related to this question:
In Excel, is it possible to automate reading of CSV data into a template and printing it to PDF from the commandline?
Is it possible to deploy a VB application made in Excel as a stand alone app?
FOCUS OF QUESTION: Again, focus of the question is if this is possible via Excel marcos, if not macros VBA, and if there's any huge issue with this approach; for example, I know this is going to be "slow" since Excel would be loaded per job, but there's 16GB of ram on the server and it's not used at all. Figure since I've got to have a copy of office on the server anyway, this is a much faster approach.
If you've got any questions, let me know via comments.
I suppose you could launch the report file from perl and then have a macro inside the report file automatically look for the newest csv file to import. Then you could process and output. So you just need to launch the proper excel file with the embedded macros from perl and then let excel and VBA take over.
Is there anyway to problematically take a MS Word file and convert to excel. (Obviously, word would to guess where to put stuff). Any language would be fine
That's a pretty wide-open question. The content of the Word document will affect how easy/hard this is.
One method you could look at is using Word automation to open the Word document and then write out a new file using comma-separated format and just name the file with a .xls extension. Upon opening this file up in Excel it should "just work".
If you need rich formatting in your output Excel document, you could use Excel automation to build your output document. Using this you'd have both Word automation (read) and Excel automation (write) in your program.
Another option that I've used (but it's a bit pricey) in a server environment is the Aspose libraries Aspose. They have a pretty nice API (at least for Word, which is what I've used) and they eliminate the automation angle.
See http://blogs.msdn.com/brian_jones/archive/2009/04/01/importing-a-table-from-wordprocessingml-to-spreadsheetml.aspx
Here is a resource on automating office applications: Office Object Models
I have an Excel file in OfficeML format, MyData.xls. Since I upgraded to Office 2007 from Office 2003 I get a warning message saying that the file content does not match the file extension. It seems that OfficeML now must have the extension 'xml'.
In my application I use OleClientSite to display the file in an OleFrame object. If I change the file extension to 'xml' then Excel is not started. If I leave the extension as 'xsl' then I get the above warning message.
How can I force the file with the 'xml' extension to be opened in the OleFrame using Excel?
The easiest solution is to switch back to the 2003 format, which should not require any changes to your application. To do this, open your file with the extension set to *.xls. When prompted with the warning ("... do you want to open the file now?"), proceed to open (this is a warning to make sure you don't unintentionally open a macro-enabled file). Once in Excel and the file is open, simply save it as *.xls. This can be done by going to "Office Button / Save As / Excel 97-2003 Workbook".
Now, the harder solution will be upgrading your application to deal with the new OfficeML format. I don't know about the component you're using, but it will likely still work for some of the binary parts in the new standard (most notably VBA projects), but you're going to have to unpack and start reading XML files.
If you haven't already done this, create a new Excel workbook, save it as *.xlsx (the 2007 format) and in Explorer, change its extension to *.zip. Open it up and take a look around. For more in-depth on the files, I would start digesting this MSDN article.
Maybe I'm missing something, but shouldn't you just use .xslx as your extension? I'm assuming that by OfficeML, you're refering to Office Open XML.
The <?mso-application progid="Excel.Sheet"?> should be present in the XSL template used.
The below link explains clearly how to include the processing instruction. I had to do something similar and it worked for me.
http://www.shareyourwork.org/roller/ralphsjavablog/entry/generating_excel_sheets_with_xslt