Hello
I was told several times that Native XLSX support will be available for AdvGridExcelIO soon
Any update on this?
Mike
www.etl-tools.com
This is dependent on Flexcel technology, so first we need to finish & release Flexcel
Any update on this one?
Mike
We are targeting for a release next week.
The week is over
Any update on this one?
We are being constantly bombarded regarding this issue
Mike
It is very close now.
Looking forward to it
I was told several times that Native XLSX support will be available for AdvGridExcelIO soon
I guess you are still working on it?
We just release FlexCel v5 with xlsx support 2 days ago. Now we are working in 2 new components, TAdvExcelReader and TAdvExcelWriter that will allow to read and write xls or xlsx files. It is working now, we are just working out the details, making the interface cleaner, etc for a release. It will be available next week.
TAdvExcelReader and TAdvExcelWriter that will allow to read and write xls or xlsx files
Any update on this?
I am constantly being asked by the customers about this beature
Mike
Hello,
We also long awaited this feature for some customers.
I just downloaded and tried the package. Actually we are using the TMS Component Pack that includes also the Grid Pack. But when we try to install the updated xls-Im-/Export we failed. As it said we need to have FlexCel installed?
We used Delphi XE2 Pro (German, SP3).
I understood this package is addressed to all users of a Grid product also?
Bye,
Dirk
As explained at:
http://www.tmssoftware.com/site/advgridfilters.asp
this is an interface between TMS Grids and TMS Flexcel to offer .XLS & .XLSX import & export capabilities.
So, it is required to have a TMS Grid installed and TMS Flexcel: http://www.tmssoftware.com/site/flexcel.asp
Hi Bruno,
thanks for the clarification. So will we see in the future also a solution for the TMS Grid component itself for this format? Or it this from a "technical" viewpoint not possible?
I understood the start of this thread was e request for the "TAdvGrid Excel IO" that is part of the TMS Grids. So that was my hope to run it on the TMS Grid pack also.
Bye,
Dirk
Hi,
TadvExcelIO includes its own FlexCel 3.x version, with all units renamed so they don't clash (because you can't install units with the same name in the IDE). While technically this was possible with v3 (it is small), FlexCel v5 has more than 1300 units, so renaming them all to include them with the grids is not really possible. Also the zipped sources of FlexCel 5 are more than 2mb (uncompressed they are more than 8mb of .pas files), so it would be a lot of code to add to the TMS grids.
Besides that, in the development of TAdvExcelIO (I've developed both AdvExcelIO and the new Reader/Writer) I always had to "restrict" what you could do with it, because it was a component to export/ import a grid to xls, not an Excel manipulator, and I had to make sure that people weren't using the embedded renamed FlexCel engine as FlexCel itself. This lead to a lot of silly restrictions, and people asking me why we couldn't remove them. I felt much better now writing the new components in that I could assume you had the full FlexCel available, so you could do whatever you wanted.
That's from the technical side: Code is too big and complex to include it with the grids, and also, doing so artificially limits what you can do with it.
To give you an example: pdf exporting is coming in the following months to FlexCel, and once it is available, it will allow you to export a grid to pdf (either by exporting it to Excel and then to pdf or directly, we are studying this right now). If this was an embedded version, I would have to leave the pdf exporting out. And Encrypted files. And so on.
So, we are keeping them both: TadvExcelIO as a simple and lightweight solution to read and write xls files, and TAdvExcelReader/Writer with FlexCel for more features, including xlsx.
So, there is no way to export Grid to xlsx format if we own TMS Component Pack?
You can, with:
AdvStringGrid1.SaveToXLS('test.xlsx');
Hi Adrian,
thank you for your detailed explanation. Just one final question regarding executable size:
If we upgrade to flexcel to be able to export to xlsx with cell format,...
How much will this blow up our source code? As you said the flexcel module consists of several units and a lot of code. Will this be bind to our applications in a smart way. So if we "just" use the export the increase in the executable size will be adequate?
May you have some hints to achieve this?
Thanks,
Dirk
Hi,
FlexCel is divided in modules, so for example adding "just" xlsx support won't add the libraries for pdf exporting. But the problem is, xlsx support is one of the 2 things that take a lot (and really a lot) of code (the other is recalculation). The reason why xlsx takes so much code is because the spec is huge and very verbose, and also because we had to implement things like our own zip support and xml readers and writers. The reason why recalculation takes so much is because we support about 300 functions and each one of them has to be implemented (and while some are simple like =sum, some others can be quite complex on their own.
What we could do to reduce a little the size is to allow a way to remove recalculation, so the exported file wouldn't be calculated when you save it, but Excel will calculate it anyway when you open it. But well, we still have to do a lot of things in FlexCel (like as said pdf and html export) and right now we re focusing in that. If we do make the recalculation optional, this will be after we finish those things. (And we will do it only if it proves that size is reduced in a significant way, if after we do it we verify that it just adds complexity, then it might not be done).
We do have plans to study size and how it can be reduced in the future, but as said, priorities right now are to get all the missing parts working. And it might not really be possible, as latest delphis tend to blow the size of any part of code a lot (and yes, we do suppress the extended RTTI)
About the actual sizes, compiling in release mode (please never do a size test in debug, Delphi can throw 20mb exe files in an empty files with a form and some buttons), the numbers for the demo app are:
Without FlexCel: 3.395 mb
With FlexCel: 9.957mb
This number isn't that important normally, since you don't really care about a 6mb package in a disk with 1tb, but what you normally really care about is the distribution size (which is zipped). So the zip numbers are:
Without FlexCel: 982 kb
With FlexCel: 2.388mb
So we are speaking about a 6.5mb size increase in the disk, and a 1.5mb in distribution. I wonder how much removing recalculation could shrink this down. But well, otoh, when you compare it with .net it is huge (the full FlexCel.dll for .net with pdf export and everything is 2.356mb, compressed to 696kb ), but if you compare it with Excel itself then it is tiny (we are speaking about hundreds of mb if you have to install Excel to do OLE Automation)
As said, we will be investigating if there is something else that we can do to reduce size, but with low priority. Right now we care more about having everything working.
Just a quick follow-up.
Running stripreloc ( http://www.jrsoftware.org/striprlc.php ) in the 9.957mb exe reduces it almost 700kb to 9.270mb.
Instead of running stripreloc, you can also add "{$SetPEFlags 1}" to your sources ( http://hallvards.blogspot.com/2006/09/hack12-create-smaller-exe-files.html )
Not really 100% related, but I think interesting anywyay. Of course, we can't do a stripreloc (or change the peplags) in FlexCel itself, but you can do it in your final exe. It will help keeping the size down.