Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Creating an Excel spreadsheet file directly from Delphi...

575 views
Skip to first unread message

Jean Dupond

unread,
Feb 19, 2008, 6:09:31 PM2/19/08
to
Does anybody know of a component that would allow a Delphi 5 application to
export formatted data into an Excel file? I found a suite of components
(named SMExport suite) from Scalabium Software. But as far as I can tell,
they don't allow formatting of the data at the Excel level. I would like to
be able to export the data as well as specify the output format (such as the
number of digits past the decimal point or 'text' rather than 'general').
Any pointers would be greatly appreciated. Thanks.


Gerald Koeder

unread,
Feb 19, 2008, 6:31:41 PM2/19/08
to
Hi Jean,

take a look at the NativeExcel-Suite from NikaSoft at
http://www.nika-soft.com/nativeexcel2/index.htm

Works very well and has a great support

Regards,
Gerald

"Jean Dupond" <jdu...@nomail.com> schrieb im Newsbeitrag
news:47bb61a9$1...@newsgroups.borland.com...

Malcolm Cheyne

unread,
Feb 19, 2008, 6:55:30 PM2/19/08
to
IIRC D5 included the "spreadsheet" component from Formula One. The company
no longer exists. Search your drive for F1*.*

I also have to look for a replacement for D2007. :-(

--

Malcolm
Townsville, Australia

"Jean Dupond" <jdu...@nomail.com> wrote in message
news:47bb61a9$1...@newsgroups.borland.com...

Paul Hughes

unread,
Feb 19, 2008, 7:12:29 PM2/19/08
to
Have a look at this link on delphi3000.com. It is a class which can write
the excel format directly - no need even to have excel installed.
http://www.delphi3000.com/articles/article_4724.asp

Here is also a link that uses the above to output a dataset to excel.
http://www.delphi3000.com/articles/article_3475.asp

Regards, Paul.

"Jean Dupond" <jdu...@nomail.com> wrote in message
news:47bb61a9$1...@newsgroups.borland.com...

Ivan

unread,
Feb 19, 2008, 8:10:39 PM2/19/08
to
Take a look at XLSReadWriteII from http://www.axolot.com/components/index.htm
Works well and is well maintained -- they are working on the new Excel format now. If you are sure
that the user will have Excel installed you already have everything you need to do ole automation.

Oliver Townshend

unread,
Feb 20, 2008, 12:00:04 AM2/20/08
to

OLE Automate Excel. Ask in the oleautomation group.

On an interesting related note,
http://www.joelonsoftware.com/items/2008/02/19.html

Oliver Townshend

DJSox

unread,
Feb 20, 2008, 12:14:05 AM2/20/08
to
You might also try TMS's TAdvStringGrid, as it can create excel worksheets
with some formatting, it used to be on the Delphi partner CD.

Dan

"Jean Dupond" <jdu...@nomail.com> wrote in message
news:47bb61a9$1...@newsgroups.borland.com...

Message has been deleted

Malcolm Cheyne

unread,
Feb 20, 2008, 7:36:51 AM2/20/08
to
> Adrian.

Thanks for the very informative facts.

--

Malcolm
Townsville, Australia

Raymond Schappe

unread,
Feb 20, 2008, 12:02:34 PM2/20/08
to
I'll second this!

NativeExcel has been working well for me too!!

And as Gerald said, the support has been great!

-Raymond

Carl Caulkett

unread,
Feb 20, 2008, 10:06:43 AM2/20/08
to
Gerald Koeder wrote:

> Hi Jean,
>
> take a look at the NativeExcel-Suite from NikaSoft at
> http://www.nika-soft.com/nativeexcel2/index.htm
>
> Works very well and has a great support

+1

I've used this and had good results from it.

--
Carl

Mike Shkolnik

unread,
Feb 20, 2008, 5:37:41 PM2/20/08
to
Hello,

you may change any exported value and formatting in OnGetCellParams event in
SMExport suite

--
With best regards, Mike Shkolnik
Scalabium Software
http://www.scalabium.com
mshk...@scalabium.com

"Jean Dupond" <jdu...@nomail.com> wrote in message
news:47bb61a9$1...@newsgroups.borland.com...

Dan Downs

unread,
Feb 20, 2008, 5:51:45 PM2/20/08
to
TMSSoftware's FlexCel

It works great, you setup an excel template, do your formatting and
formulas on that and code a little to fill in the data. Its very very
easy to do simple database to excel stuff. Without to much more work
master-detail type stuff is pretty easy too.


DD

Oliver Townshend

unread,
Feb 21, 2008, 5:49:48 AM2/21/08
to
An interesting reply. It probably comes down to the quality and complexity
of the spreadsheet required.

I'm surprised that Microsoft haven't supplied a server version of Office if
they are pushing an XML format which then they tell you must be put on a
workstation and can't be on a server (unattended).

Oliver Townshend

Message has been deleted
Message has been deleted

Malcolm Cheyne

unread,
Feb 21, 2008, 8:17:11 AM2/21/08
to
> Well, sorry because this post got so long, I tend to get very
> passionate about this issues ;) Hope it wasn't too boring.

Adrian

I enjoyed the read. Very informative.

--

Malcolm
Townsville, Australia


Woody (TMW)

unread,
Feb 21, 2008, 11:48:02 AM2/21/08
to
Adrian Gallero wrote:
>
>> I enjoyed the read. Very informative.
>
> Thanks! I wondered if someone would read it all... so it is nice to
> have feedback. Well, time to get back to work...

I read it with interest as well. I've hit a roadblock I can't overcome,
yet, so I'm searching for answers. It seems that Excel2007 doesn't like
the save commands when using ole objects to control it. All my code with
statements like wb.save or wb.saveas (where wb refers to a workbook
variant) return errors and I don't know why. I know that 2007 went to
mostly a com interface but it should still support the ole code,
according to everything I've read.

Oh well, back to my searching...

Woody (TMW)

Jean Dupond

unread,
Feb 21, 2008, 2:19:26 PM2/21/08
to
Thanks for all your input and suggestions.

Since I am already testing the SMExport suite from Scalabium Software, I
will try to use the OnGetCellParams method as suggested by the company.

If I am unsuccessful, I will take a look at the different components that
were suggested withon your responses.

As a last resort, I will look into OLE.

FYI: even though producing a 'csv' file would be fairly simple. It is not
an option as the users do not want to have to 'format' the results (within
Excel during the file opening).


"Jean Dupond" <jdu...@nomail.com> wrote in message
news:47bb61a9$1...@newsgroups.borland.com...

Oliver Townshend

unread,
Feb 21, 2008, 11:14:52 PM2/21/08
to
> And while I don't agree with the conclusions, I do agree with the body
> of Joel's article: Coding a spreadsheet yourself by using the office
> binary file reference is not a smart idea. It is like writing to a
> database by directly modifying the file where data is stored instead of
> using SQL. It is not because the file formats are bad, it is because
> they are complex and they must be and you need an API to access them.

Yes, many years ago (1996?) I got a copy of the Word Binary Format and wrote
a program to extract data from it. . But when Office 97 came out, it
didn't quite work and I switch to OLE Automation, which is the API I
suppose. We had to sign confidentialy clauses for the format, so it sat in
a draw for a long time until I tossed it out. Interesting to see it is now
avaialble. Since then I've always used Ole Automation or VBA Macros to
achieve the results I want. Obvioulsy our paths diverged at this point and
I ended up doing less Delphi than I would have liked as a result.

> This means you can have a file with macros, a pivot table, some activex
> components and even an embedded word document, open it with FlexCel,
> insert some rows, change cells values, and save it back. And the macro,
> the pivot table, the word document, everything will still be there,
> even when FlexCel does not know how what to do with them.

Interesting point. Makes it a useful format to work with I suppose.

> In many ways, FlexCel or openoffice will display an Excel 2003 file
> much better than Excel 2007. And even so, people uses Excel 2007 and
> that is fine, because we don't really need that 100% compatibility that
> doesn't exist anyway. We always settle for imperfect solutions after
> all.

I think that's because they totally rewrote the 16 bit display routines to
work in a 32 and 64 bit environment. There was a very interesting
analysis of the whole thing in an article I read, but I can't find it now.
It highlights the problems involved in re-writing code, and probably
explains why each version of Office looks almost exactly the same as the
previous one, because change is painful.

Oliver Townshend

Oliver Townshend

unread,
Feb 21, 2008, 11:18:41 PM2/21/08
to
> I think that's because they totally rewrote the 16 bit display routines to
> work in a 32 and 64 bit environment. There was a very interesting
> analysis of the whole thing in an article I read, but I can't find it now.
> It highlights the problems involved in re-writing code, and probably
> explains why each version of Office looks almost exactly the same as the
> previous one, because change is painful.

Found it! http://www.lomont.org/Math/Papers/2007/Excel2007/Excel2007Bug.pdf

Very interesting.

Oliver Townshend

Message has been deleted
0 new messages