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.