I need to determine which version of Microsoft Excel is installed on a Windows PC. I'm working with Apache POI but can't figure out an easy way to do this.
Anyone know if Apache POI has a built in functionality to do this? Any ideas how to do this using Java code?
POI provides a mechanism for writing Excel documents without using any of the Excel APIs. I doubt it has a mechanism to detect the installed version, as it has no dependency on an installed version of Excel.
Following a pattern similar to the one described in this question about detecting the Excel version in .NET, you could use JACOB to detect the installed Excel version like so:
ActiveXComponent xl = new ActiveXComponent("Excel.Application");
try {
xl.getProperty("Version");
} finally {
xl.invoke("Quit", new Variant[] {});
}
I really, really don't think POI has this functionality, as it's explicitly written to work cross-platform. It only deals with document files.
If I were faced with this task, I'd dig into the registry (via the Windows API) for the association of the .XLS file type. That will, err should give you a link to the most recently and completely installed Excel. Not reliably, because
there might not be an Excel installed;
the user might have changed the association; or
the Excel pointed at by the association might be broken.
But given the hint of (usually) the applicable executable, you could then examine either the .EXE file header of Excel or perhaps something in the surrounding files to determine Excel's version.
Ok it just occured to me that older Microsoft Excel versions have file extensions .xls and new ones have .xlsx.
I can just get reference to the file and get the file extensions... that easy.
If anyone has a better solution please let me know.
Related
Is there any java api which is similar to open xml sdk 2.0. Just I need to convert open office xml excel file to .xlsx file.
office xml excel file I'm creating by using xml and xslt. I tried apache poi to read xml excel file but getting invalid header format exception.
Thanks.
Well, I believe the best API out there to handle *.xlsx files is Apache POI (it has *.xlsx support since 3.7 or so).
Some alternatives:
There was a project called JExcel API, but there's not much activity there in the last 3 or so years (and I'm not sure if it handles *.xlsx format, only *.xls, but I might be wrong).
I'm not sure, but the OpenOffice UDK might also help you. Unfortunately it is only a binding, and requires an installed implementation (i.e., you have to install OpenOffice in order to use it), which is not always a valid requirement on the server side if you do not have any X servers there.
Another option is something like using it through Jacob via COM. The pro is that you are able to access all ow the data, the con is COM, you need an installed Excel on your machine (and of course, it is a Windows-specific solution).
I believe the best way to stick to Apache POI, it is usually perfectly enough if you just want to read/write cell data.
I has a excel file with 4 excel sheets in it. Now i want to read or write to required excel sheets using java without using any third party lib.
I know i can read and write data using FileInputStream and FileOutputStream respecitvely. But i can handle the work sheets??
No, you can'not, There is numerous way in Java for reading/writing files, but there is no built-in support for MS Office/Excel spreadsheets. http://poi.apache.org/ - is a key to victory.
If your goal is to interface with data from an excel sheet from your Java application, I'd suggest to use the solutions suggested by other posters, it will save you a lot of work.
If, however, you want to be able to read excel files from Java (or any other programming language for that matter) 'just because you can' then you could take a look at this file and read the instructions on this web-page. I would warn you that it would take considerably more time to implement your own API if you base it only on the file-specs that are publicly available. You might want to check out the work done by the people from the Apache POI project to get an idea of how to approach it. Or (even better) contribute to the project. Here you can find out how to go about doing that
Is there a way to convert a xls file into a pdf?
I want to make a dynamical report directly to pdf file, but didn't find a way to make dynamic columns on iReport, so I've made a method on Java that exports to xls dynamically.
So I was wondering if is there a way to convert this file to pdf, but it need to be on a method from my code. Or if you have a better idea, it can be used too.
Maybe there's a way to make this pdf file from my code as I did with xls. Please help me out.
Thanks.
Try using iText http://itextpdf.com/ - I've used it to create PDFs with columnar structure.
In addition to using iText directly, there are a couple report engines that sit on top of it:
Eclipse BIRT (using 2.1.7, the last MPL/LGPL version)
Jasper Reports (which uses a Very Old version, 1.3.1 IIRC)
This is a commercial solution:
http://www.dancrintea.ro/xls-to-pdf/
If you want open source try jakarta POI.
Try using the Muhimbi PDF Converter Services. It comes with a Java compatible Web Services based interface and sample code. It does other things as well.
I worked on this application, so the usual disclaimer applies.
I've seen various means of reading (and writing) Excel spreadsheets. For example:
In .Net as an ADO.Net source (as per Reading Excel files from C#);
In Java with either JExcelAPI ("jxl") or Apache POI;
In PHP with the Excel Spreadsheet Writer (as per Format text in Excel file via PHP and PHP:Writing to excel file using PEAR).
But I'm interested in more than just reading/writing Excel files. I want something where I can evaluate arbitrary Excel formulas. So far in this vein I've seen:
C# Excel Interop, although this seems to require that you have Excel running; and
POI-HSSF: this formula support seems incomplete.
Are there better options or is that it?
SpreadsheetGear for .NET is compatible enough with Excel that Microsoft uses it to calculate Excel based calculators on their MSN Money web site.
If you're only targeting the windows platform, you really have no substitute for running Excel, and controlling it via a COM bridge.
As you are finding, any other solution is likely to be
incomplete, and/or
incompatible and/or
inconsistent
with Excel.
Unfortunately, this does add a dependency on Excel to your software.
If you want to evaluate Excel formulae, frankly Excel is the only reliable way to do this. So running Excel via a COM bridge is the way to go.
I've done this before in Java using JACOB and that works very nicely. Excel looks after all the functionality. You just have to populate your spreadsheet (in memory) and let Excel do the rest.
The interop library is slow and needs MS Office installed.
Many times you don't want to install MS Office on servers.
I'd like to use Apache POI, but I'm on .NET.
I need only to extract the text portion of the files, not creating nor "storing information" in Office files.
I need to tell you that I've got a very large document library, and I can't convert it to newer XML files.
I don't want to write a parser for the binaries files.
A library like Apache POI does this for us. Unfortunately, it is only for the Java platform. Maybe I should consider writing this application in Java.
I am still not finding an open source alternative to POI in .NET, I think I'll write my own application in Java.
For all MS Office versions:
You could use the third-party components like TX Text Controls for Word and TMS Flexcel Studio for Excel
For the new Office (2007):
You could do some basic stuff using .net functionality from system.io.packaging. See how at http://msdn.microsoft.com/en-us/library/bb332058.aspx
For the old Office (before 2007):
The old Office formats are now documented: http://www.microsoft.com/interop/docs/officebinaryformats.mspx. If you want to do something really easy you might consider trying it. But be aware that these formats are VERY complex.
Check out the Aspose components. They are designed to mimic the Interop functionality without requiring a full Office install on a server.
As the new docx formats are inherently XML based files, you can create and manipulate them programmatically with standard XML DOM techniques, once you know the structure.
The files are basically zip archives with an alternate file extension. Use the System.IO.Packaging namespace to get access to the internal elements of the file, then open them into a XmlDocument to perform the manipulation.
There are examples available for doing this, and the Office Open XML project on SourceForge may be worth looking at for inspiration.
As for the older binary formats, these were proprietary to MS, and the only way you're likely to get at the content from within is through the Office object model (requires an Office install), or a third party file converter/parser.
Unfortunately there's nothing first party and native to the .NET platform to work with these files.
What do you need to do with those file? If you just want to stream them to the user, then the basic file streams are fine. If you want to create new files (perhaps based on a template) to send to the user that the user can open in Office, there are a variety or work-arounds.
If you're actually keeping data in Office documents for use by your web site, you're doing it wrong. Office documents, even Excel spreadsheets and access databases, are not really an appropriate choice for use with an interactive web site.
If the document is in word 2007 format, you can use the system.io.packaging library to interact with it programatically.
RWendi
In Java world, there is also JExcelApi. It is very clearly written, from what I was able to see, much cleaner then POI. So maybe even a port of that code to .NET is not out of the question, depending of course you have enough of time on your hands.
OpenOffice.
You can program against it and have it do a lot for you, without spending the money on a license for the server, or have the vulnerability associated with it on your server.
Microsoft Excel workbooks can be read using an ODBC driver (or is it an OLE DB driver? can't remember) that makes the workbook look like a database table. But I don't know whether that driver is available without the Office Suite itself.
You can use OpenOffice. It has a command-line conversion tool:
Conversion Howto
In short, you define a macro in OpenOffice and you call that macro with a command-line
argument to OpenOffice. In that argument the name of the local file (the Office file) is
encoded.
It's not a great sollution, but it should be workable.