This article is a little bit different in that it's the beginning of a project I'm been thinking about for a little while. At the very least if I take it no further my scribblings may save someone some time.
First the why
The beauty of having open documents is that as a software developer I can make a package for disribution to my customer without worrying about licenses. This just feel much more wholesome to me. So I've looked at various options (ActiveX OpenOffice, dlls etc), but they all involve driving someone elses code. One of the reference books available is called OASIS OpenDocument Essentials and in it is this little snippet that sums up my general feeling.
When talking about storing in a propriety format rather than an open format.
Note also that your data can become inaccessible when the software vendor moves to a new internal format and stops supporting your current version. (Some people actually suggest that this is not cause for complaint since, by putting your data into the vendor’s proprietary format, the vendor has now become a co-owner of your data. This is, and I mean this in the nicest possible way, a dangerously idiotic idea.)
J. David Eisenberg
What I actually need is a way to generate a spreadsheet checklist for all the VIs in a project.
So what is the OpenDocument format.
Wikipedia sums it up thus.
The Open Document Format for Office Applications (ODF), also known as OpenDocument, is an XML-based file format for spreadsheets, charts, presentations and word processing documents. It was developed with the aim of providing an open, XML-based file format specification for office applications
Stuff I've learnt....
OD File Structure
If you save an OpenOffice or LibreOffice file it will save as an ODS (for a spreadsheet), ODT (for a word processing document) or ODP (for a presentation). These are a JAR format file, this being Java Archive or simply put a ZIPped package where some of the contents are NOT compressed. Here's one unzipped.
My first hurdle was not compressing mimetype.
Here's how I did it (using the Open G Advanced Compression VIs, doctored so that I can set the compression type)
The file that does all the work is content.xml and here's what I've learnt about this bad boy. The best way to describe it is to show a spreadsheet with some data and display the xml and then describe how they get there.
NOTE: the XML is from a spreadsheet where the columns haven't been squashed for artistic license, the xml for the one shown may therefore have more column info to describe the cell size.
After some headscratching and surprisingly little help from the internet I fathomed that it works like this....
The 3 table:table-column nodes describe the 1st column, the 2nd column with added width and then the remaining columns
We then have 13 table:table-row nodes that contain the cell information.
Of course this all looks lovely and ordered but the file really looks something like this.
So I'll be using the DOM xml parser VIs and some XPath for searching out the nodes.
My plan is to make a polymorphic container type component where the polymorphic selector is the command. This will wrap the LVOOP document classes. With methods to Load, Save, Save As, Add Cell to Table, Add Array to Table, Get Cell Data, Get Cell Data Type.
If anyone is interested I'll post the code (it may be useful to use github to allow methods to be added)
Next step is to do some UML diagrams of the class structure. But that's for another day.