Open Office

  • Thread starter Thread starter Stephen Plotnick
  • Start date Start date
S

Stephen Plotnick

I have a program that creates a spreadsheet in Excel.

The company would like to now have Excel installed on computer. I put in all
interop DLL's but program blows up. They are going to use open office to
open up spreadsheet when I'm done.

IS there a way to create spreadsheet without Excel on computer or can I
modify program to use open office instead of Excel. We have proven the
spreadsheet I create does work in Open Office.
 
Stephen Plotnick said:
I have a program that creates a spreadsheet in Excel.

The company would like to now have Excel installed on computer.
Click to expand...

Which computer?
I put in all interop DLL's but program blows up.
Click to expand...

You put the PIA's where?
They are going to use open office to open up spreadsheet when I'm done.

IS there a way to create spreadsheet without Excel on computer or can I
modify program to use open office instead of Excel. We have proven the
spreadsheet I create does work in Open Office.
Click to expand...

If OpenOffice is on each of the client PC's and you know that OO can open
your Excel file, then what's the problem exactly?

Can you be more specific?

-Scott
 
I have a program that creates a spreadsheet in Excel.

The company would like to now have Excel installed on computer. I put in all
interop DLL's but program blows up. They are going to use open office to
open up spreadsheet when I'm done.

IS there a way to create spreadsheet without Excel on computer or can I
modify program to use open office instead of Excel. We have proven the
spreadsheet I create does work in Open Office.
Click to expand...

Sure, there are several commercial libaries for creating binary excel files
without having excel on the machine. One I played with that I found to be
good was here : http://www.bytescout.com

100% .NET code, no need for excel, and compared to others reasonably priced.

Another option, if you don't need to include vba macro's in your generated
spreadsheets is to generate them in SpreadSheetML format. This is what I do
most of the time - it's XML after all :) You can download the schema's from
microsoft. You might want to stick to the 2003 reference schema's if you are
planning to work with OOo. It seems to understand those fairly well...
 
I have a program that creates a spreadsheet in Excel.

The company would like to now have Excel installed on computer. I put in all
interop DLL's but program blows up. They are going to use open office to
open up spreadsheet when I'm done.

IS there a way to create spreadsheet without Excel on computer or can I
modify program to use open office instead of Excel. We have proven the
spreadsheet I create does work in Open Office.
Click to expand...
You can always write the data as .dif (See
http://en.wikipedia.org/wiki/Data_Interchange_Format for definition and
examples). This way you can set the formatting, etc, that can't be done in
a simple .csv file.

Richard
 
Stephen Plotnick said:
I have a program that creates a spreadsheet in Excel.

The company would like to now have Excel installed on computer. I put in all
interop DLL's but program blows up. They are going to use open office to
open up spreadsheet when I'm done.

IS there a way to create spreadsheet without Excel on computer or can I
modify program to use open office instead of Excel. We have proven the
spreadsheet I create does work in Open Office.
Click to expand...

If Excel is not installed on the machine, then the interop assemblies don't
do you any good. You need Excel on the machine you are installing.

Mike
 
Family Tree Mike said:
If Excel is not installed on the machine, then the interop assemblies
don't
do you any good. You need Excel on the machine you are installing.

Mike
Click to expand...

I sure hesitate to disagree with you Mike because I know that in general you
know this stuff better than I do. But not too long ago I transfered
development of an application which generates an Excel spreadsheet to a new
machine without Excel. At first it did not work, but after I installed the
interop assemblies it did. Unfortunately I did eventually spring for the
latest and cheapest Office package, so if my memory as to what happened when
is faulty then I could be wrong.

I'll dig around a bit and see if I can find a definitive statement one way
or the other in Interop documentation.

Bob
 
eBob.com said:
I sure hesitate to disagree with you Mike because I know that in general
you know this stuff better than I do. But not too long ago I transfered
development of an application which generates an Excel spreadsheet to a
new machine without Excel. At first it did not work, but after I
installed the interop assemblies it did. Unfortunately I did eventually
spring for the latest and cheapest Office package, so if my memory as to
what happened when is faulty then I could be wrong.

I'll dig around a bit and see if I can find a definitive statement one way
or the other in Interop documentation.

Bob
Click to expand...

Mike is absolutely correct that if you don't have Excel installed on your
machine then the InterOp assemblies (PIA's) don't do you any good.

The whole point of the PIA's is that they provide a Runtime Callable Wrapper
(RCW) for your .NET code to call, when trying to manipulate the Excel
product. If you don't have the Excel product, the PIA's won't help. The
PIA's act as a "middle-man" between your .NET applicaiton and Excel.

-Scott
 
eBob.com said:
I sure hesitate to disagree with you Mike because I know that in general you
know this stuff better than I do. But not too long ago I transfered
development of an application which generates an Excel spreadsheet to a new
machine without Excel. At first it did not work, but after I installed the
interop assemblies it did. Unfortunately I did eventually spring for the
latest and cheapest Office package, so if my memory as to what happened when
is faulty then I could be wrong.

I'll dig around a bit and see if I can find a definitive statement one way
or the other in Interop documentation.

Bob
Click to expand...

My only guess at how this _might_ have worked is if there was an eval
version of office on the machine.
 
Family Tree Mike said:
My only guess at how this _might_ have worked is if there was an eval
version of office on the machine.
Click to expand...

More likely my memory is just faulty. So does this mean that if someone
hired me to write them an application which created an Excel spreadsheet I'd
have to ask them what level of Excel they had and then buy and install that
same level on my development machine?

Thanks, Bob
 
eBob.com said:
More likely my memory is just faulty. So does this mean that if someone
hired me to write them an application which created an Excel spreadsheet I'd
have to ask them what level of Excel they had and then buy and install that
same level on my development machine?

Thanks, Bob


.
Click to expand...

You should be fine if you build your code using the earliest version you
wish to support. For example, if you build referencing Office 2003, your
code should be fine on a 2003, 2007, or presumably 2010 Office machine.

Mike
 
In think there is a license issue as well. To get the relevant Excel bits on
the server you need a license.

--

Rod Gill



eBob.com said:
I sure hesitate to disagree with you Mike because I know that in general
you know this stuff better than I do. But not too long ago I transfered
development of an application which generates an Excel spreadsheet to a
new machine without Excel. At first it did not work, but after I
installed the interop assemblies it did. Unfortunately I did eventually
spring for the latest and cheapest Office package, so if my memory as to
what happened when is faulty then I could be wrong.

I'll dig around a bit and see if I can find a definitive statement one way
or the other in Interop documentation.

Bob


__________ Information from ESET Smart Security, version of virus
signature database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com
Click to expand...

__________ Information from ESET Smart Security, version of virus signature database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com
 
Back
Top