I was wondering if there was a way to have more than 255 columns for inputting data for users who have Excel 2010.
Any news on this? Actually, support for more than 255 columns started in Excel 2003 (I'm told). I'm trying to use tAdvGridExcellIO to export an advstringgrid contents ans get stopped by max_columns being greater than 255. Editing
tmsXlsMessages.pas to increase Max_columns lets me create the export, but then Excel 2010 doesn't want to read it.
What is the real solution?
Thanks.
You'd need to use the new XLSX file format.
About support for this file format, this was recently discussed on our newsgroup, the answer is copied here:
Before answering, there is one thing that I am not sure everybody is aware
of, but the VCL v5 and .NET v5 versions are the same code. Code is
translated automatically by a modified mono compiler from c# to delphi, so
all the code that we write in .NET is automatically converted to delphi,
and we have to review it manually later.
That is the reason you have
been seeing more .NET releases, when we
released 5.0 xlsx support was very
basic and the equivalent vcl version
would have been very basic too. At
that time I severely underestimated the
work that would be needed to have a
complete xlsx working version, because
the xlsx file format is really, and
I mean really overengineered. But
well, from 5.0 to 5.5 we have just been
adding feature after feature to
xlsx support in .NET, and automatically the
VCL version has been getting
those too. But we have really lacked the time
to put everything together
in vcl, and that's the reason you haven't seen a
vcl release yet. Every
time we added a feature we had to add it in both
places to keep them in
sync, and so, while vcl hasn't been released yet, it
has been getting all
those new features, that are what have been keeping it
delayed.
Sometimes it gets difficult to see the scope of this project,
but we are
coding an Excel clone twice, in .NET and in VCL. We are speaking
about
150,000 lines of C# code, and even when we have an automatic
translator to
delphi that works incredibly well, the time needed just to
review all of
them and fix small differences is huge (manual fixes are
needed mainly
because delphi doesn't have garbage collection and because
some libraries
like the xml lib or the graphics lib work different and we
need to adapt
the calls).
Now I don't want this to look as an
excuse, there is no valid excuse to be
made here and I assume all the
responsibility for being late. But I also
wanted for people to know that
this is not that we are forgetting about
vcl, in fact TMS is mostly a full
Delphi shop and we are very serious
about Delphi support. The reason is
that we need to write the code first
in .NET so it can be translated to
VCL. The good part is that once the
first port is ready releases will be
mostly at the same time. We could
have chosen other path of having 2
completely different codebases, but
being realistic, it wouldn't have been
possible to keep them both in sync
when we add new features.
I can't
give a time frame yet, we now have a lot of new code from 5.5 too
to port
back (that's mostly what I have been doing last week), but also
have delphi
XE2 to care about, which comes with a lot of new things. I am
doing all I
can to have it ready for XE2 release, because I am not sure
old codebase
will work with 64 bits, and I don't want to lose time porting
that.
Well that's what I can say. But there is also another thing
that I would
like to say and that I was planning to say in a blog when
everything is
nearest release, but this is probably a good time to mention.
Last
December, I realized that most of the manual adjustments we were doing
to
the code were because the lack of a lot of modern features in old
Delphis,
lack of generics, lack of records with methods, lack of unicode
support,
lack of hashtables, lack of lambdas and so on, things that were
used in
the .NET codebase and hadn't an automatic translation. All of those
things
were adding a lot of work and complexity to the codebase, and I
think it
was never going to be ready with this. So we have decided to cut
support
for versions < 2009. FlexCel 3 will keep working on those
versions, but
the new codebase will require a modern compiler. I understand
that this
will be a problem to a lot of users, but really the choice is
about having
a modern codebase available in a reasonable timeframe and keep
waiting and
waiting. Once we cut that support things have been going much
faster, but
they did take a hit with 5.5. I should be writing with more
news soon.
of, but the VCL v5 and .NET v5 versions are the same code. Code is
translated automatically by a modified mono compiler from c# to delphi, so
all the code that we write in .NET is automatically converted to delphi,
and we have to review it manually later.
That is the reason you have
been seeing more .NET releases, when we
released 5.0 xlsx support was very
basic and the equivalent vcl version
would have been very basic too. At
that time I severely underestimated the
work that would be needed to have a
complete xlsx working version, because
the xlsx file format is really, and
I mean really overengineered. But
well, from 5.0 to 5.5 we have just been
adding feature after feature to
xlsx support in .NET, and automatically the
VCL version has been getting
those too. But we have really lacked the time
to put everything together
in vcl, and that's the reason you haven't seen a
vcl release yet. Every
time we added a feature we had to add it in both
places to keep them in
sync, and so, while vcl hasn't been released yet, it
has been getting all
those new features, that are what have been keeping it
delayed.
Sometimes it gets difficult to see the scope of this project,
but we are
coding an Excel clone twice, in .NET and in VCL. We are speaking
about
150,000 lines of C# code, and even when we have an automatic
translator to
delphi that works incredibly well, the time needed just to
review all of
them and fix small differences is huge (manual fixes are
needed mainly
because delphi doesn't have garbage collection and because
some libraries
like the xml lib or the graphics lib work different and we
need to adapt
the calls).
Now I don't want this to look as an
excuse, there is no valid excuse to be
made here and I assume all the
responsibility for being late. But I also
wanted for people to know that
this is not that we are forgetting about
vcl, in fact TMS is mostly a full
Delphi shop and we are very serious
about Delphi support. The reason is
that we need to write the code first
in .NET so it can be translated to
VCL. The good part is that once the
first port is ready releases will be
mostly at the same time. We could
have chosen other path of having 2
completely different codebases, but
being realistic, it wouldn't have been
possible to keep them both in sync
when we add new features.
I can't
give a time frame yet, we now have a lot of new code from 5.5 too
to port
back (that's mostly what I have been doing last week), but also
have delphi
XE2 to care about, which comes with a lot of new things. I am
doing all I
can to have it ready for XE2 release, because I am not sure
old codebase
will work with 64 bits, and I don't want to lose time porting
that.
Well that's what I can say. But there is also another thing
that I would
like to say and that I was planning to say in a blog when
everything is
nearest release, but this is probably a good time to mention.
Last
December, I realized that most of the manual adjustments we were doing
to
the code were because the lack of a lot of modern features in old
Delphis,
lack of generics, lack of records with methods, lack of unicode
support,
lack of hashtables, lack of lambdas and so on, things that were
used in
the .NET codebase and hadn't an automatic translation. All of those
things
were adding a lot of work and complexity to the codebase, and I
think it
was never going to be ready with this. So we have decided to cut
support
for versions < 2009. FlexCel 3 will keep working on those
versions, but
the new codebase will require a modern compiler. I understand
that this
will be a problem to a lot of users, but really the choice is
about having
a modern codebase available in a reasonable timeframe and keep
waiting and
waiting. Once we cut that support things have been going much
faster, but
they did take a hit with 5.5. I should be writing with more
news soon.