CustomDocumentProperties

I'm currently evaluating Flexcel and need to be able to read/write CustomDocumentProperties. I've had a look through the docs but can't see a way to do this - is it possible?


Thanks, Bob

Hi,


Sadly currently no. At this moment FlexCel will only read xls properties. We have plans for near future to add reading and writing of xlsx properties. But no plans to add writing of xls properties, since they are just a mess. xls properties are quite complex (incredibly complex actually) to write, including creating red-black trees and a lot of other stuff that makes it very hard to do it right, and they aren't that much required either, so as said, no plans at the moment.

What we normally recommend to the people wanting to edit properties is this free dll from Microsoft:
http://support.microsoft.com/kb/224351


Thanks Adrian - I'm only interested in Excel 2007 onwards, so xlsx is fine. Any idea on timescales? If I purchase now could I get early access to a beta with CustomDocumentProperties. TBH, looking at the structure of the xlsx, I was thinking I could probably modify the code myself. The custom doc properties are just stored as xml.


Bob

Hi,

Indeed custom properties in xlsx aren't complex, the reason we haven't implemented them yet was because we need to make them compatible with the existing api for reading xls props, and also because well, demand for writing properties is very little.

It should be ready this year, but I can't promise a more detailed timescale. There are 2 things we still miss in xlsx: Conditional formats and properties, and this is what we are working right now. (besides reporting for FlexCel for VCL and the dll to use it from older delphi versions). We should be able to give you a beta once it is ready too, just let me know if you need it and I can add your email to my notification list.

Thanks Adrian - I'll go ahead and order. I had a disappointing moment loading one of my monster spreadsheets into the FMX demo - it took 40sec to load vs Excel's 6 sec. However, the VCL demo loaded the file in approx the same time as Excel, so it seems to be an FMX issue.


Bob

Hi,


It is weird that firemonkey should be that much slower (unless it was in OSX instead), since we don't really use FM canvas, we use GDI+ for both FM and VCL.

If you want and data is not confidential, you can send me the file to adrian@tmssoftware.com and I'll see if there is something wrong with it.

About performance, what I can say is that, despite what many people believes, Excel is very fast. It is coded in C+assembly but some of the best coders in the world, and compiled in a cutting edge optimizing C compiler, not in an aging Delphi compiler (Which was cutting edge 10 years ago, but not today). You would expect it to be faster.

People often gets confused because OLE Automation is very slow, so if you wanted to fill a spreadsheet with ole automation, it would be much slower than any native solution. But Excel itself is quite fast.

 We normally are in par with Excel speed and memory usage, but this means things like we use our own optimized xml reader and writer, our own optimizes zip library, our own optimized streamreader and so on, since if we used stock RTL components it would be quite slower. We also profile a lot and make the code as fast as we can't, but we try not to sacrifice flexibility or security. For example, all FlexCel code is compiled with {$R+}, even when not strictly necessary, and when using $R- would be faster (and probably any other competing library is compiled with r-. And of course, Excel itself is compiled without range checking, since that doesn't exist in C ). But we prefer to leave range checking on, because it can help avoid buffer overflows and nasty bugs. Other thing we do is to save with a higher level of compression of the zip file than Excel: Again slower, but the generated xlsx files are smaller. We try not to compromise to get the maximum possible speed, and I think that anyway we are quite fast.
 
As a general rule, you can expect similar speeds in FlexCel as Excel (or even a little faster) when reading and writing files, but we are slower when recalculating (because as it is a component designed for a server, it normally recalculates just once at save time, while Excel needs to recalculate every time you change a cell).