Archive<< January 2020 >>
- A Blog about the Blog
- Online training courses for TMS WEB Core at reduced price!
- Curious about our new technologies, new challenges & new products for 2020?
- Using EurekaLog with TMS Logging
- Adrian Gallero (21)
- Bart Holvoet (3)
- Bernard Roussely (1)
- Bruno Fierens (233)
- Gjalt Vanhouwaert (3)
- Holger Flick (15)
- Marcos Douglas B. Santos (5)
- Masiha Zemarai (32)
- Nancy Lescouhier (32)
- Pieter Scheldeman (24)
- Roman Yankovsky (2)
- Tunde Keller (3)
- Wagner R. Landgraf (63)
BlogAll Blog Posts | Next Post | Previous Post
Tuesday, December 13, 2011This isn't a particularly easy to write post. There are so many things to say, many good news, some bad ones, that it gets hard to decide where to start.
So let's try to start from what you should already know from the title: FlexCel 5 for VCL and FireMonkey is coming, bringing full feature parity with FlexCel .NET (and this includes things like xlsx/m support, exporting to pdf, exporting to html, full recalculation, new reporting engine, and so many other things that I can't just mention them all). Also, we are making available a public preview of the core engine today to all our registered users. You can get it from the registered users page.
The not so good newsOn the not-so-nice side, I have two things to mention:
- FlexCel 5 will need Delphi XE or newer. This was a very difficult decision, as we know a lot of you people are still in Delphi 7. We have our download stats that give us a nice outlook on how many people is in each version, and while Delphi 7 is certainly going down, it still is big.
But we really had no choice. As you might know, FlexCel 5 for VCL is based in FlexCel for .NET codebase, and the .NET codebase makes heavy use of things like generics, class variables, records with methods, nullable types, hashtables, class constructors, and let's not forget real Unicode support and Unicode conversion functions. There are also many bugs that have been fixed in newer versions, and that would have to be workarounded to support older versions.
In our first tries at creating FlexCel for VCL we tried to workaround all of those somehow: A record with a method can be converted to a helper function on that record, a generic type can be auto generated with a tool. We could search for unicode support methods somewhere, or write our own. But well, somewhere along the way we realized that we will never be able to get this working at all if we had to first code our own Delphi XE on top of Delphi 7 in order to code FlexCel on top of that. FlexCel on its own is over half million lines of code, getting that to work was enough work.
We needed the Delphi 2009 feature list at least. Problem is, generics support in D2009 and 2010 is so buggy, that it gets impossible to compile FlexCel with them. XE and XE2 aren't perfect either, but the bugs are not too serious and can be workarounded.
But also we are trying to look a little into the future. Embarcadero is releasing about a version per year, and that means in some months we will be seeing XE3, and a year after XE4, and soon we will be supporting also a lot of versions in FlexCel 5. We need to test, profile, workaround bugs in every version that we support, and at the rate new Delphis keep coming, we can't keep forever supporting Delphi 5.
What we do plan to do once we launch FlexCel 5 and if demand for older Delphi keeps strong, it is to provide a dll compiled with XE2 that can be used from any Delphi version, or any other programing tool. We understand it is not the best way, but it is better than deploying Excel, and we think it is a reasonable compromise.
- FlexCel 5 is not 100% compatible with FlexCel 3. Personally I am a big fan of backwards compatibility, even if today it seems a little out of fashion and everybody seems to advocate killing it. As a FlexCel user myself, I don't appreciate having older apps breaking because of a change in FlexCel. But FlexCel for VCL was getting old, with many design decisions going back to its first version in 1996, and there will never be a better time to modernize it than now. I did learn a couple of things since 1996, or I want to believe I did. What things were confusing, too complex, or just could be done better.
I did apply many of those things when creating FlexCel.NET (as I had no backwards compatibility to care about), and I am very happy on how it turned out. In fact, I liked it so much that this is what FlexCel for VCL will look like. On the API side it doesn't mean much, some methods renamed (for example "CellValue" property is now a pair of Get/SetCellValue methods, because indexed properties bring a lot of trouble for C++ Builder). But all in all it should be very simple to convert the code, as there isn't any change for the sake of change, and most things remain the same. I have myself converted the examples with minimal work. On the report side changes are more complex, and even when I plan to ship a semi automatic converter, things don't map that well. But I really believe it is worth it, the new reporting engine is just so much better.
On the bright side, we will be shipping a TXLSXAdapter that you can use with FlexCel 3 components, and that uses FlexCel 5 inside, and so it provides xlsx and xls support for FlexCel 3. You will be able to keep using the old FlexCel 3 in parallel with FlexCel 5, and convert the complex reports as you need.
The good newsOk, so with the bad things out of the way, what is good? After all I wrote on the bad side, I am kind of ashamed that all the good news can be sumarized in 3 words: "FlexCel 5 Rocks". I have mentioned that I can't really enumerate all new things coming in the space of a blog, but if you are really interested, You can look at what's new for FlexCel VCL since V3 . Not everything applies to Delphi, but most of it does. And both not-so-good items in the other section also have their upside. As we broke some of the backward compatibility, we get a nicer foundation to build on in the following years. And as we don't support old Delphi versions, code is much cleaner and nicer. We have things like a "TCellValue" record that can be automatically converted to and from strings, numbers, formulas, etc, working much better than the variants we had to use in FlexCel 3. We've been able to inline a lot of code and optimize unicode strings in ways that wouldn't be possible if we had to support Delphi 5.
But there is probably something even better than the fact that FlexCel 5 for VCL is good. And that is that FlexCel VCL will be kept in synch with FlexCel.NET from now on. Actually, it already is in synch, it has moved from 5.5 to 5.6 at the same time as FlexCel .NET did. It got chart preservation and xls 5 support at the same time as .NET did. It got all the same bug fixes the .NET version did. And all of this is because, as we realized that the biggest problem was not getting feature parity but maintaining it, we spend a lot of time writing automated tools to help us keep both codebases together. They are kind of fascinating (at least for me), and sometimes they seem to work as magic, and as you guessed I am going to write about them soon. Just not here, as this post already got too long. Remember though that of course FlexCel 5 for VCL is 100% Delphi source code that compiles to native executables! FlexCel 5 is also faster than FlexCel 3 in all the benchmarks we tried, and that is not saying little, since FlexCel 3 was quite fast.
What's in the previewAs the name says, this is a PREVIEW. Not even a beta. While the core engine is working, and you will be able to run the demos, code is nowhere near production yet, we have a very big list of known issues to fix before we can call it a beta. So please don't install it in any production machine, and don't use it for any serious work. This is not a "Google beta" that can be used anyway.
Also, for this release we are focusing on the API, so the report and rendering engines, even when included, are commented out and not working. We plan into getting the Core Engine working first, and soon the rest. Core engine is 400,000 of the 500,000 lines of code anyway, so a lot of work is done.
We would love to hear feedback from you. But just don't send in bug reports yet, we are aware of most bugs, and just haven't got time to fix them. Having thousands of reports in things we know they don't work yet will just delay us. On the other hand, things you can report are issues with the installer or any performance issues (a file taking too much to load, for example). Those things should be working fine fine, and we will investigate any report about them right away.
FinallyI still can't give a final date for release, as while there is a lot of work done, there is work remaining. It is just a very big project, even if sometimes I forget how much, and there are thousands of things to take care of. But things are going very smoothly lately (much more so since we decided to drop old Delphi support), and an usable release is not far away. We will be updating this preview very often, I expect about once a week, until the final version arrives. In a couple of releases we should be having a beta, and some more releases after that the final version. If you want to be informed as we release them, I will be mentioning them in Twitter: https://twitter.com/#!/adriangallero/
Ps: If you want to look at the files we are generating but don't feel like installing the preview, here are some examples:
Simple xlsx file showing images, merged cells, formulas and formatting. (Created in OSX with FireMonkey)
Xlsm file showing Macro and chart preservation, true colors, etc.
Xlsx file created with a very early version of AdvGridExcelIOPro. This file corresponds to Example 46 of AdvStringGrid. Note how html text is converted to rich formated text in Excel. Also, we manually added a checkbox from FlexCel, the final version should convert checkboxes automatically from the grid to Excel.
This blog post has received 5 comments.
All Blog Posts | Next Post | Previous Post