On Thursday, August 19, 2004 9:34:28 AM UTC+1, martin durtschi wrote:
Hello out there.

I got the following problem, which I can neither explain nor solve.
I would be glad if anybody could help me out.

My Excel is a german Excel 2000.

My application uses automation to export data to Excel and also sets
cell formats. The end user's Excel could be any language, so - of
course - the application will set the NumberFormat property, which
is language independant.

Using a COM client like VB 6 or VBA works perfectly well; i can set
the NumberFormat property to e.g. "d/m/yy", which causes the
NumberFormatLocal property to be "T/M/YY" - the german
representation of date formats.

But my Application is .NET/C#, automating Excel through an interop
wrapper.

What happens is that the wrapper's NumberFormat property seems to be
mapped to Excel's NumberFormatLocal property.
So for a cell with the above format, both NumberFormat and
NumberFormatLocal return "T/M/YY", and setting NumberFormat to
"d/m/yy" throws the very same exception as one gets when trying to
set NumberFormatLocal to "d/m/yy".

I suspect this behaviour to be a problem of COM interoperability,
globalization or a combination of the two.

I'd appreciate any
- explanation of the behaviour
- solution
- workaround (besides trying to work with the NumberFormatLocal
property)

Thanks for any help
- martin durtschi

Well, this issue still exists 10 years later, and I haven't found a
solution yet.

VB6/VBA automated instances of Excel are created using CreateObject(),
and interact directly with the object variable used. Are you saying C#
doesn't have such a function so you can interact directly with your
instance?

Also, setting number format in VB6/VBA is done on the Range object
directly. Are you saying C# also has no way to do that either?

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion