How to create an excel file through a C program

J

jeniffer

I need to create an excel file through a C program and then to populate
it.How can it be done?
 
J

jacob navia

jeniffer said:
I need to create an excel file through a C program and then to populate
it.How can it be done?

This is not really on topic here but...
#include <windows.h>
#include <shellapi.h>
#include <stdio.h>
int main(void)
{
FILE *ExcelFile = fopen("testdata.csv","w");
if (ExcelFile == NULL)
return -1;
fprintf(ExcelFile,"Column1,Column2,Column3\n1,2,3\n");
fclose(ExcelFile);
ShellExecute((HWND)0,"open","testdata.csv",NULL,NULL,SW_SHOW);
}

Compiled with lcc-win32
http://www.cs.virginia.edu/~lcc-win32
 
I

Ian Collins

jeniffer said:
I need to create an excel file through a C program and then to populate
it.How can it be done?
Ask microsoft for the file format, then write the code to produce the file.
 
J

jacob navia

In 100% standard C you can do it with

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *ExcelFile = fopen("testdata.csv","w");
if (ExcelFile == NULL)
return -1;
fprintf(ExcelFile,"Column1,Column2,Column3\n1,2,3\n");
fclose(ExcelFile);
system("D:\\Program Files\\Microsoft Office\\Office\\excel.exe
testdata.csv");
return 0;
}
 
V

Vladimir Oka

jeniffer opined:
I need to create an excel file through a C program and then to
populate it.How can it be done?

By learning about Excel file format (if M$ lets you), which is
off-topic here. Once you do, and you have some C code that gives you
troubles, feel free to come back here for help.

On the most basic level, you'd need `fopen()`, `fwrite()`, and friends
from <stdio.h>.
 
W

Walter Roberson

I need to create an excel file through a C program and then to populate
it.How can it be done?

fopen() the file with "wb" (write binary) mode, and
then fwrite() or fprintf() or putc() or fputc() whatever you need to.

You should probably avoid putw() and fputs(), though:
putw() works in terms of the type "int", which is not the same
size on all systems; and fputs() includes a terminating newline,
which is not the same character(s) on all systems.


What you need now is to know what the structure is of an excel file.
That's a topic beyond the scope of standard C, and is
subject to change without notice from Microsoft ("Documenting
a file structure hurts our ability to innovate!!") Inc.

You can find a long paper on the file format by googling for
excel file structure
for example, http://sc.openoffice.org/excelfileformat.pdf
has OpenOffice's documentation up to Excel 2003. You will likely
find the mass of information there rather daunting, and chances
are extremely high that if you were to attempt to implement the
full range yourself that you (or anyone) would make mistakes.
I would therefor suggest to you that you should either attempt to
find a pre-written Excel library (perhaps OpenOffice offers one),
or else that you take a big portability hit by confining yourself
to Windows and using one of Microsoft's development APIs.
Microsoft's APIs are discussed in microsoft-specific newsgroups.
 
Z

Zero

jeniffer said:
I need to create an excel file through a C program and then to populate
it.How can it be done?

Better you use in this case Visual Basic! Much easier and comfortable.
 
B

Ben C

I need to create an excel file through a C program and then to populate
it.How can it be done?

Probably create a .csv file (which you can do with normal fprintf and
string processing in C), and use Excel to import that.

Otherwise there is possibly a library, or some way to use Excel as a
co-process, you'd have to find out about Office and Microsoft
architecture.
 
J

jacob navia

Flash said:
Of course, if you had used the system call provided by the standard you
would not have needed the non-standard headers and it would have
compiled and worked with many more compilers. Such as the gcc
implementation that is part of Cygwin.

I did exactly that, see my other post
 
J

jacob navia

Keith said:
That's 100% standard and 0% portable -- and it doesn't satisfy the
original requirements.

Apart from the other non-portabilities that have already been
mentioned, I do have MS Excel on my computer, but it's not on my DVD
drive (D:).

If your program is inherently non-portable, there's little point in
avoiding the use of non-standard extensions that will do the job
better than system() can. Of course, the use of such extensions would
make the program off-topic in this newsgroup -- which merely means
that it should be discussed in a *different* newsgroup, possibly one
full of experts who might know better ways of creating Excel files.

The ShellExecute makes possible to ignore the path of the excel
executable. system() is not that clever, and the path is in this case
hardwired. The program is thus non-portable, but can be made to work in
any machine with Excel with very little effort :)

Of course, lcc-win32 offers the possibility of using the dispatch
interface of Excel and dynamically populating the cells, making excel
display a graphic of the data, whatever. But if I would have posted that
it would have been a 1500 line program full of windowish code... shudder.

Let's keep it at that. If the original posted is interested, we can
discuss that in the lcc group.

jacob
 
J

jacob navia

Walter Roberson a écrit :
"it" refered to "create an excel file and populate it".





That does not create an excel file: at most it creates a file that excel
is able to read.

Well, an "excel file" is a file excel can read, I suppose :)
Returning -1 from main() would have an implementation-defined effect.
As you are already including <stdlib.h>, why not use EXIT_FAILURE
instead?

This is true. That would be better.

The system() call is irrelevant to the original problem of creating
and populating an excel file, and makes the program much less portable.

There is another problem with the code that could arise especially
in Germany: comma might be the decimal delimeter (the equivilent
to the decimal point), and the field delimeter expected might be
the semi-colon. The 1,2 in the file might be interpreted as 1 + 2/10
(1.2) instead of as indicating the boundary between two cells.

That could be fixed with LC_LOCALE and seeing what the german version of
excel does...
 
C

CBFalconer

jeniffer said:
I need to create an excel file through a C program and then to
populate it. How can it be done?

FILE *excelfile;

if (NULL == (excelfile = fopen("filename", "w")))
exit(EXIT_FAILURE);
else {
while (suitableconditions) fwrite(excelfile, data);
}
fclose(excelfile);

You will have to define filename, suitableconditions, and data for
yourself.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
 
A

Andrew Poelstra

Zero said:
Better you use in this case Visual Basic! Much easier and comfortable.
You scum. VB isn't a language. "Languages" work in more than one
environment.

My friend made a one-window app with two prompts and nothing else, and
it took up 3 megs of RAM. I made the same thing in C (with curses), and
it used about 50K, which seemed like a lot to me at the time...
 
V

void * clvrmnky()

Andrew said:
You scum. VB isn't a language. "Languages" work in more than one
environment.
Well, the requirements include an application that is basically only
available on one platform. In this case VB (or one of the embedded
VB-like thingies in Office) would be a decent choice.

If your design deliberately limits you to one platform then there is
small value in trying to be portable, especially for version 1. At my
shop we have the other problem; trying to make reasonably portable
extensions that can also talk to the madness that is Office.

Good, fast or cheap. Choose any two.
 
F

Flash Gordon

jacob said:
This is not really on topic here but...

Then why post it here?
#include <windows.h>
#include <shellapi.h>
#include <stdio.h>
int main(void)
{
FILE *ExcelFile = fopen("testdata.csv","w");
if (ExcelFile == NULL)
return -1;
fprintf(ExcelFile,"Column1,Column2,Column3\n1,2,3\n");
fclose(ExcelFile);
ShellExecute((HWND)0,"open","testdata.csv",NULL,NULL,SW_SHOW);
}

Compiled with lcc-win32
http://www.cs.virginia.edu/~lcc-win32

Of course, if you had used the system call provided by the standard you
would not have needed the non-standard headers and it would have
compiled and worked with many more compilers. Such as the gcc
implementation that is part of Cygwin.
 
W

Walter Roberson

In 100% standard C you can do it with

"it" refered to "create an excel file and populate it".

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *ExcelFile = fopen("testdata.csv","w");
if (ExcelFile == NULL)
return -1;
fprintf(ExcelFile,"Column1,Column2,Column3\n1,2,3\n");
fclose(ExcelFile);
system("D:\\Program Files\\Microsoft Office\\Office\\excel.exe
testdata.csv");
return 0;
}

That does not create an excel file: at most it creates a file that excel
is able to read.

Returning -1 from main() would have an implementation-defined effect.
As you are already including <stdlib.h>, why not use EXIT_FAILURE
instead?

The system() call is irrelevant to the original problem of creating
and populating an excel file, and makes the program much less portable.

There is another problem with the code that could arise especially
in Germany: comma might be the decimal delimeter (the equivilent
to the decimal point), and the field delimeter expected might be
the semi-colon. The 1,2 in the file might be interpreted as 1 + 2/10
(1.2) instead of as indicating the boundary between two cells.
 
K

Keith Thompson

jacob navia said:
In 100% standard C you can do it with

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *ExcelFile = fopen("testdata.csv","w");
if (ExcelFile == NULL)
return -1;
fprintf(ExcelFile,"Column1,Column2,Column3\n1,2,3\n");
fclose(ExcelFile);
system("D:\\Program Files\\Microsoft Office\\Office\\excel.exe
testdata.csv");
return 0;
}

That's 100% standard and 0% portable -- and it doesn't satisfy the
original requirements.

Apart from the other non-portabilities that have already been
mentioned, I do have MS Excel on my computer, but it's not on my DVD
drive (D:).

If your program is inherently non-portable, there's little point in
avoiding the use of non-standard extensions that will do the job
better than system() can. Of course, the use of such extensions would
make the program off-topic in this newsgroup -- which merely means
that it should be discussed in a *different* newsgroup, possibly one
full of experts who might know better ways of creating Excel files.
 
K

Keith Thompson

jacob navia said:
Keith said:
jacob navia <[email protected]> writes:
[snip]
Of course, lcc-win32 offers the possibility of using the dispatch
interface of Excel and dynamically populating the cells, making excel
display a graphic of the data, whatever. But if I would have posted
that it would have been a 1500 line program full of windowish
code... shudder.

It would also probably have been closer to what the OP was actually
looking (in the wrong place) for.

Trying to generate a valid ".xls" file using only standard C would be
silly. The only reason I can think of to do so is if you have a
requirement to generate such a file on non-Windows systems, or perhaps
on Windows systems on which Excel isn't installed (something that the
original poster didn't explicitly ask for). Microsoft, which controls
the ".xls" format, is unlikely to be very helpful in meeting such a
requirement.

Excel files use a system-specific format, requiring system-specific
code to deal with them. There is nothing wrong with writing
system-specific code when it's appropriate (any fools who think I'm a
"religious fanatic" on this point please take note); this just isn't
the place to discuss the details.
Let's keep it at that. If the original posted is interested, we can
discuss that in the lcc group.

Bravo! I hope this becomes a habit.

(If this can be done with features that are specific to Windows but
not to lcc-win32, perhaps an MS Windows programming group would be
more appropriate. Since I really don't know much about those details,
I'm only guessing here.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top