Converting to/from a string without regard to culture

[John Brown]

Hi there,

Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of Windows.
You use the "TypeConverter" for this structure to generate the string, say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given that
the system presumably won't recognize the comma anymore (only a period).
Conversely, how do you convert a "Size" object back to a culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter" class
to write my string in a consistent way given that it has to be read back in
on a thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.

[John Brown]

Does anyone know how to go about reading/writing a type to a file in a

language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of
Windows. You use the "TypeConverter" for this structure to generate the
string, say, "50, 75" which you then store in a file (or perhaps a DB).
Now, the same value might later be read back in from this file on a
Japenese version of Windows (or more accurately on a thread where the
culture is set to Japanese). Let's say the comma (",") is actually a
period (".") in Japanese however though I'm just making this up for
demonstration purposes. How do you now convert the original value "50, 75"
into a "Size" object given that the system presumably won't recognize the
comma anymore (only a period). Conversely, how do you convert a "Size"
object back to a culture-independent string (in this case using a comma)
so that it can be processed on the original English machine again. Or
maybe this isn't as complicated as I'm making it out to be. I'm just not
sure how to use the "TypeConverter" class to write my string in a
consistent way given that it has to be read back in on a thread running
with a different "CutlureInfo". Can anyone provide any insight on the
matter. Thanks very much.

Ok, I'm thinking that I need to call
"TypeConverter.ConvertToInvariantString()" to write the value and
"TypeConverter.ConvertFromInvariantString()" to read it back in. However,
once read back in using the latter function, I then need to pass the value
to "TypeConverter.ConvertToString()" if I actually want to display it (since
I assume "ConvertToString()" is culture-sensitive). Conversely, if a user
enters the string in some field during data-input, I would need to convert
it using "TypeConverter.ConvertFromString()" and then pass this back to
"TypeConverter.ConvertToInvariantString()" before writing it to file again.
Is this correct? Thanks.

[Jon Skeet [C# MVP]]

John Brown <no_spam@_nospam.comwrote:

Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of Windows.
You use the "TypeConverter" for this structure to generate the string, say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given that
the system presumably won't recognize the comma anymore (only a period).

Have you tested this assumption? I would hope that TypeConverter was
already culture-independent, but I haven't tried it.

Conversely, how do you convert a "Size" object back to a culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter" class
to write my string in a consistent way given that it has to be read back in
on a thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.

I'd say the first thing to do is to make sure there's actually a
problem. Try exactly the situation you fear will fail.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pax]

The comma you are talking about is actually part of the language, C#, it is
a list separator, and therefore it's got nothing to do with localization!
"John Brown" <no_spam@_nospam.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're
dealing with the native "System.Drawing.Size" type on an English version
of Windows. You use the "TypeConverter" for this structure to generate
the string, say, "50, 75" which you then store in a file (or perhaps a
DB). Now, the same value might later be read back in from this file on a
Japenese version of Windows (or more accurately on a thread where the
culture is set to Japanese). Let's say the comma (",") is actually a
period (".") in Japanese however though I'm just making this up for
demonstration purposes. How do you now convert the original value "50,
75" into a "Size" object given that the system presumably won't recognize
the comma anymore (only a period). Conversely, how do you convert a
"Size" object back to a culture-independent string (in this case using a
comma) so that it can be processed on the original English machine again.
Or maybe this isn't as complicated as I'm making it out to be. I'm just
not sure how to use the "TypeConverter" class to write my string in a
consistent way given that it has to be read back in on a thread running
with a different "CutlureInfo". Can anyone provide any insight on the
matter. Thanks very much.

Ok, I'm thinking that I need to call
"TypeConverter.ConvertToInvariantString()" to write the value and
"TypeConverter.ConvertFromInvariantString()" to read it back in. However,
once read back in using the latter function, I then need to pass the value
to "TypeConverter.ConvertToString()" if I actually want to display it
(since I assume "ConvertToString()" is culture-sensitive). Conversely, if
a user enters the string in some field during data-input, I would need to
convert it using "TypeConverter.ConvertFromString()" and then pass this
back to "TypeConverter.ConvertToInvariantString()" before writing it to
file again. Is this correct? Thanks.

[pax]

Sorry, my bad, it seems that the list separator IS part of the Regional
Options :)
"pax" <pa*@noname.comwrote in message
news:ub**************@TK2MSFTNGP03.phx.gbl...

The comma you are talking about is actually part of the language, C#, it
is a list separator, and therefore it's got nothing to do with
localization!
"John Brown" <no_spam@_nospam.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>>Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're
dealing with the native "System.Drawing.Size" type on an English version
of Windows. You use the "TypeConverter" for this structure to generate
the string, say, "50, 75" which you then store in a file (or perhaps a
DB). Now, the same value might later be read back in from this file on a
Japenese version of Windows (or more accurately on a thread where the
culture is set to Japanese). Let's say the comma (",") is actually a
period (".") in Japanese however though I'm just making this up for
demonstration purposes. How do you now convert the original value "50,
75" into a "Size" object given that the system presumably won't
recognize the comma anymore (only a period). Conversely, how do you
convert a "Size" object back to a culture-independent string (in this
case using a comma) so that it can be processed on the original English
machine again. Or maybe this isn't as complicated as I'm making it out
to be. I'm just not sure how to use the "TypeConverter" class to write
my string in a consistent way given that it has to be read back in on a
thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.

Ok, I'm thinking that I need to call
"TypeConverter.ConvertToInvariantString()" to write the value and
"TypeConverter.ConvertFromInvariantString()" to read it back in. However,
once read back in using the latter function, I then need to pass the
value to "TypeConverter.ConvertToString()" if I actually want to display
it (since I assume "ConvertToString()" is culture-sensitive). Conversely,
if a user enters the string in some field during data-input, I would need
to convert it using "TypeConverter.ConvertFromString()" and then pass
this back to "TypeConverter.ConvertToInvariantString()" before writing
it to file again. Is this correct? Thanks.

[AlexS]

Can CultureInfo.InvariantCulture property help you to achieve required
result?
"John Brown" <no_spam@_nospam.comwrote in message
news:uA**************@TK2MSFTNGP04.phx.gbl...

Hi there,

Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of
Windows. You use the "TypeConverter" for this structure to generate the
string, say, "50, 75" which you then store in a file (or perhaps a DB).
Now, the same value might later be read back in from this file on a
Japenese version of Windows (or more accurately on a thread where the
culture is set to Japanese). Let's say the comma (",") is actually a
period (".") in Japanese however though I'm just making this up for
demonstration purposes. How do you now convert the original value "50, 75"
into a "Size" object given that the system presumably won't recognize the
comma anymore (only a period). Conversely, how do you convert a "Size"
object back to a culture-independent string (in this case using a comma)
so that it can be processed on the original English machine again. Or
maybe this isn't as complicated as I'm making it out to be. I'm just not
sure how to use the "TypeConverter" class to write my string in a
consistent way given that it has to be read back in on a thread running
with a different "CutlureInfo". Can anyone provide any insight on the
matter. Thanks very much.

[John Brown]

Thanks for the feedback...

John Brown <no_spam@_nospam.comwrote:

>Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're
dealing
with the native "System.Drawing.Size" type on an English version of
Windows.
You use the "TypeConverter" for this structure to generate the string,
say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in
Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given
that
the system presumably won't recognize the comma anymore (only a period).

Have you tested this assumption? I would hope that TypeConverter was
already culture-independent, but I haven't tried it.

I can't find any documenation that clarifies the situation but I'm fairly
certain that it isn't (culturally-independent). How could it be for instance
when commas and other types of punctuation can differ from one culture to
another (which is readily apparent simply by looking at regional settings in
the control panel). Moreover, customized type conversions may be influenced
by locality and that's something you can never escape. Finally, a quick look
at some of the "TypeConverter()" functions clearly indicates that culture
does come into play but I can't pin down the precise rules.

>

>Conversely, how do you convert a "Size" object back to a
culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter"
class
to write my string in a consistent way given that it has to be read back
in
on a thread running with a different "CutlureInfo". Can anyone provide
any
insight on the matter. Thanks very much.

I'd say the first thing to do is to make sure there's actually a
problem. Try exactly the situation you fear will fail.

You can't accurately test this however without actually installing a
localized version of Windows or possibly using the Windows MUI (Multi User
Interface) pack which really isn't a (completely) accurate test IMO. The MUI
pack isn't available through normal retail channels in any case. I'd like to
know what the rules actually say rather than just relying on ad hoc tests.
Anyway. thanks again for the feedback.

[John Brown]

Can CultureInfo.InvariantCulture property help you to achieve required

result?

Maybe (probably perhaps) but I'm still looking into the matter as mentioned
in my initial follow-up post. I think
"TypeConverter.ConvertToInvariantString()" and cousins are probably the key.

[=?Utf-8?B?UGV0ZXIgUml0Y2hpZSBbQyMgTVZQXQ==?=]

Size size = new Size(1,2);
TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(Size));
String text = typeConverter.ConvertToInvariantString(size);
size = (Size)typeConverter.ConvertFromInvariantString(tex t);

Which is jus short-hand for:
text = typeConverter.ConvertToString(null, CultureInfo.InvariantCulture,
size);
size = (Size)typeConverter.ConvertFromString(null,
CultureInfo.InvariantCulture, text);

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#
"John Brown" wrote:

Hi there,

Does anyone know how to go about reading/writing a type to a file in a
language (culture) independent way. For instance, let's say you're dealing
with the native "System.Drawing.Size" type on an English version of Windows.
You use the "TypeConverter" for this structure to generate the string, say,
"50, 75" which you then store in a file (or perhaps a DB). Now, the same
value might later be read back in from this file on a Japenese version of
Windows (or more accurately on a thread where the culture is set to
Japanese). Let's say the comma (",") is actually a period (".") in Japanese
however though I'm just making this up for demonstration purposes. How do
you now convert the original value "50, 75" into a "Size" object given that
the system presumably won't recognize the comma anymore (only a period).
Conversely, how do you convert a "Size" object back to a culture-independent
string (in this case using a comma) so that it can be processed on the
original English machine again. Or maybe this isn't as complicated as I'm
making it out to be. I'm just not sure how to use the "TypeConverter" class
to write my string in a consistent way given that it has to be read back in
on a thread running with a different "CutlureInfo". Can anyone provide any
insight on the matter. Thanks very much.

[John Brown]

Size size = new Size(1,2);

TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(Size));
String text = typeConverter.ConvertToInvariantString(size);
size = (Size)typeConverter.ConvertFromInvariantString(tex t);

Which is jus short-hand for:
text = typeConverter.ConvertToString(null, CultureInfo.InvariantCulture,
size);
size = (Size)typeConverter.ConvertFromString(null,
CultureInfo.InvariantCulture, text);

Ok, thanks. It appears that the use of "InvariantCulture" is probably the
key so at least I can go from here.

[Jon Skeet [C# MVP]]

John Brown <no_spam@_nospam.comwrote:

Have you tested this assumption? I would hope that TypeConverter was
already culture-independent, but I haven't tried it.

I can't find any documenation that clarifies the situation but I'm fairly
certain that it isn't (culturally-independent). How could it be for instance
when commas and other types of punctuation can differ from one culture to
another (which is readily apparent simply by looking at regional settings in
the control panel). Moreover, customized type conversions may be influenced
by locality and that's something you can never escape. Finally, a quick look
at some of the "TypeConverter()" functions clearly indicates that culture
does come into play but I can't pin down the precise rules.

My mistake - I'd somehow thought you were talking about a serializer.
However, it certainly does look like the ConvertToInvariantString calls
are what you're after.

I'd say the first thing to do is to make sure there's actually a
problem. Try exactly the situation you fear will fail.

You can't accurately test this however without actually installing a
localized version of Windows or possibly using the Windows MUI (Multi User
Interface) pack which really isn't a (completely) accurate test IMO. The MUI
pack isn't available through normal retail channels in any case. I'd like to
know what the rules actually say rather than just relying on ad hoc tests.
Anyway. thanks again for the feedback.

Well, just changing the culture of the current thread and seeing
whether you can still retrieve the data accurately would be a good test
to start with, I'd say. I completely understand about wanting more than
tests though :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too