Build 3.5.0.11 of xlsgen introduces several fixes to the formula parser.

- more strict validation of defined names being inserted to an Excel file. The names are checked against additional invalid characters. Invalid characters include spaces and colons, to name a few.

- insertion of unknown names whenever applicable in formulas. Before this, the parsing of unknown names would abort and the entire formula would be lost. But Excel does not behave this way when it reads an existing file. So xlsgen mimics just that. If xlsgen encounters an unknown name, it creates a special entry for it internally (marked as for deletion, as in Excel), and the parsing carries on, meaning that such formulas are preserved as is. Before this build, a lost formula would have caused, as a result, the loss of the object attached to it, such as a data validation object, only because the missing formula would make it not valid. This is now a thing of the past.

- support for literal expressions such as #REF!:#REF!

- performance improvements : no longer detection of error tokens in the main parsing phase.

Build 3.5.0.10 of xlsgen has two fixes related to the behavior of vector shapes.

The first fix improves the anchoring of vector shapes when they are being read from a XLSX file. In the past, there could have been an offset of one cell horizontally and vertically.

The second fix is for the behavior of text rotation (both the angle and the vertical nature if applicable) so that it is consistent across reading and writing XLS and XLSX files.

Build 3.5.0.9 of xlsgen exposes two additional properties of OLE objects in XLS and XLSX files.

These additional properties are for cases where the file type cannot be inferred because there is no such information stored in the Excel file.

It so happens that, when you insert an OLE object in an Excel file, Excel will store information relative to the program associated to the file type installed on one's computer, not a standard MIME file type that could be shared internationally. As a result, any Excel file, by design, cannot work properly if you happen to try to open it and you don't have on your computer the one or more applications associated to run the OLE objects. In this scenario, all what Excel does is show you a screen capture of the OLE object, which is actually stored in the file so there is nothing being inferred or generated. And when you double-click on the OLE object, you get an error message saying the OLE server cannot start, or something of that nature.

To ease the pain, xlsgen introduces two properties that are meant, for a client application, to recognize the actual file type so something more relevant than what Excel does, can be done with the OLE object in question.

The additional properties are :

- FileContentType : this is the progId of the file being stored as an OLE object. Usually, the progId of the application installed on that computer, which is associated to the file type. For instance, if you read PDF using "Free PDF Reader", the progId will be a string identifying this application.

- ServerGUID : the server GUID associated to the OLE object is again another application selection string. It strictly identifies an application installed on that computer.