• View latest product updates, release history, component descriptions
• Stay in touch with the latest blog articles as they are written
• Instantly view latest TMS tweets
• Detailed product information with the latest updates
• Read our blog, check our tweets
• See what"s new, what"s improved, what"s fixed in our components
• View latest Youtube training videos from the tmssoftwareTV"s channel

What"s included?

Launch schedule:

• Full recalculation support: We found some showstopper bugs and had to disable recalculation in v5.0, but it will be coming as soon as we can possibly fix the problem.


• APIMate: APIMate is a tool that tells you how to code an Excel sheet. You open an xls/xlsx file created with Excel in APIMate, and it will tell you the exact Delphi code you need to create that file. As with recalculation, APIMate is internally working and I hoped it would make the initial release, but it had some bugs (related to RTTI in initialized enums) that made us delay it.


• If possible, C++ Builder support: I am not 100% sure if this one is even possible, the truth is that Delphi produces completely bonked hpp headers for FlexCel that won"t even compile. After some investigation headers could manually be fixed, but there are also bugs in the way Rad Studio returns records (C structs) to C++ builder, causing AVs when some records are returned. As said, we still need to investigate this in depth so I can"t say much more until we do.


• Encrypted files xls and xlsx files: Support for encrypted files is already in the shipped 5.0 code, but not enabled since we need to code our own encryption algorithms like SHA1 and AES for it to work. At the moment the code just calls some abstract interfaces for SHA1 and AES and will not open encrypted files.


• Documentation and demos: We should be improving a lot in the documentation, providing F1 help, and adding many new demos. APIMate should help a lot with the learning curve too.


• Stability fixes: As with any first release, we expect to find many small issues that we will be fixing in this 5.1 release.

• Reporting Engine: A completely rewritten report engine that will allow a lot of new stuff in Reports. A converter from v3 reports to v5 reports will be included.

• Rendering Engine: Exporting xls/x files to pdf, html or images. Printing and previewing Excel files.

Structural changes

var
  xls: TXlsFile;
begin
  xls := TXlsFile.Create(true);
  try
     DoSomething(xls);
  finally
     xls.Free;
  end;
end;

TExcelAdapter was an abstract class that provided an interface between an actual Excel file and the components doing the work. We originally provided two different implementations of TExcelAdapter: TXlsAdapter (native interface) and TOleAdapter (interface using OLE Automation). Then you could plug TFlexCelReport into a TXlsAdapter and have a report generated natively, or plug it to an OLE Adapter and have the report generated by OLE Automation.

This was a nice abstraction and it worked fine at the beginning (when we only had a FlexCelReport component), but with the introduction of FlexCelImport (a component that was originally designed to only read xls files as its name implies, but later was expanded to also write files) things got a little too complex.

As you can see in the diagram, you have an "Adapter" and a "FlexCelImport" class that do mostly the same. So most of the methods (but not all) in FlexCelImport, just call the same method in the ExcelAdapter engine. This meant not only a lot of redundant code (and redundancy is one of the main things that we want to avoid), but also a lot of confusion in users who didn"t know what to use, if ExcelAdapter or FlexCelImport. We explained in the documentation that you should use FlexCelImport and not ExcelAdapter, but people kept using ExcelAdapter. And when people keeps doing the "wrong" thing despite what the docs say, this normally means not a problem in the docs or the users, but a deeper problem in the conceptual design of the code. This wasn"t as intuitive as it could be.

The last problem with this architecture was that FlexCelImport was at the same level as FlexCelReport, so they couldn"t "see" each other. The design was top-down, and the components at the top can only know about the components at the bottom. So in the places where FlexCelReport allowed hand-optimization of the code, it had to expose an Adapter component (the only thing it knew about) and not a FlexCelImport component. But you were supposed to use FlexCelImport to do manual modifications in the file, not the Adapters.

If we sit back and take a look from the distance, all the problems came from the fact that FlexCelImport was added as a separate layer over the Adapter components, and it didn"t had to be that way. So, in v5 we only have one class to read and write Excel files, and it is at the bottom where everybody else can use them, as it should be. There is no more FlexCelImport in v5, and the scheme looks something like this:

Where now the abstract class to read and write is TExcelFile, and the native implementation of that class is TXlsFile. All the code you used to use with FlexCelImport, should use TXlsFile now instead.

Migration from v3 to v5

Thanks

• March 26-27, 2012: London, UK
• March 29-30, 2012: Amsterdam, The Netherlands
• April 16-17, 2012: Washington DC/Baltimore, USA
• April 19-20, 2012: Chicago, USA
• May 14-15, 2012: Frankfurt, Germany
• May 17-18, 2012: Rome, Italy