Mult-language dialogs.

[Dave Harris]

Need some advice on how I can selectively access values from a resource. If
I have a dialog and I turn "Localization" to true, nearly every value set in
InitializeComponents() is gathered as a value from a resource and casted to
the correct type.

For the most part, I need only the "text" property, sometimes the size
property and occasionally the location property. It is a waste of time and
space to run the rest of the values through the lookup. The overhead is
pretty immense. Best I can tell the compile size of InitiaizeComponents() +
default resouce is approximately 5 times larger with than without
localization.

I took a 1.8 meg UI intensive DLL, turned all these flags on which resulted
in a DLL that was 5.4 megs.

Any advice appreciated. Thanks.

[Marius Groenendijk]

Dave,

Been there too. Furthermore the framework doesn't allow making
CultureInfos for some of the language-country combinations that
we require so we rolled our own resource management.

Source file, Xml easy to process with XmlReader :
<Xlation>
<Mnemonic>HelloWorld</Mnemonic>
<Text>Bonjour Monde</GuiText>
</Xlation>

This we store in our own ResourceManager (e.g. a HashTable)
Subclass the System.Windows.Forms.Form. In OnLoad or in the
constructure you recursively loop through the controls.
In our approach the *original* (design time) Text of a control
is taken as the Mnemonic for its translation. So a button text
"HelloWorld" would be translated into "Bonjour Monde".

In fact our approach is more sophisticated than that but I hope
you get the gist of it.

In our app, the code that loops through the controls also takes
care of translated tooltips configuring the help provider and has
an intelligent look at the control (e.g. you wouldn't want to
'translate' a text box or a datagrid for ex).
As for sizing controls, this is done automatically (if necessary)
using MeasureString after having translated the controls
(e.g. length of "Bye" vs. "Hasta la Vista"). Using Docking you
shouldn't have to worry too much about positioning but if this can be
a problem in complex screens (we have rolled our own positioning stuff
for multi-lingual data entry forms).

Size of the app doesn't grow and InitializeComponents remains unchanged
No satellite DLLs, maintaining the texts is easy; just edit the Xml.
So far we're quite happy with what we did.

HTH & Greetings,
Marius.

"Dave Harris" <Dave Ha****@discussions.microsoft.com> wrote in message
news:52**********************************@microsof t.com...

Need some advice on how I can selectively access values from a resource.
If
I have a dialog and I turn "Localization" to true, nearly every value set
in
InitializeComponents() is gathered as a value from a resource and casted
to
the correct type.

For the most part, I need only the "text" property, sometimes the size
property and occasionally the location property. It is a waste of time
and
space to run the rest of the values through the lookup. The overhead is
pretty immense. Best I can tell the compile size of InitiaizeComponents()
+
default resouce is approximately 5 times larger with than without
localization.

I took a 1.8 meg UI intensive DLL, turned all these flags on which
resulted
in a DLL that was 5.4 megs.

Any advice appreciated. Thanks.

[Marius Groenendijk]

Dave,

Been there too. Furthermore the framework doesn't allow making
CultureInfos for some of the language-country combinations that
we require so we rolled our own resource management.

Source file, Xml easy to process with XmlReader :
<Xlation>
<Mnemonic>HelloWorld</Mnemonic>
<Text>Bonjour Monde</GuiText>
</Xlation>

This we store in our own ResourceManager (e.g. a HashTable)
Subclass the System.Windows.Forms.Form. In OnLoad or in the
constructure you recursively loop through the controls.
In our approach the *original* (design time) Text of a control
is taken as the Mnemonic for its translation. So a button text
"HelloWorld" would be translated into "Bonjour Monde".

In fact our approach is more sophisticated than that but I hope
you get the gist of it.

In our app, the code that loops through the controls also takes
care of translated tooltips configuring the help provider and has
an intelligent look at the control (e.g. you wouldn't want to
'translate' a text box or a datagrid for ex).
As for sizing controls, this is done automatically (if necessary)
using MeasureString after having translated the controls
(e.g. length of "Bye" vs. "Hasta la Vista"). Using Docking you
shouldn't have to worry too much about positioning but if this can be
a problem in complex screens (we have rolled our own positioning stuff
for multi-lingual data entry forms).

Size of the app doesn't grow and InitializeComponents remains unchanged
No satellite DLLs, maintaining the texts is easy; just edit the Xml.
So far we're quite happy with what we did.

HTH & Greetings,
Marius.

"Dave Harris" <Dave Ha****@discussions.microsoft.com> wrote in message
news:52**********************************@microsof t.com...

Need some advice on how I can selectively access values from a resource.
If
I have a dialog and I turn "Localization" to true, nearly every value set
in
InitializeComponents() is gathered as a value from a resource and casted
to
the correct type.

For the most part, I need only the "text" property, sometimes the size
property and occasionally the location property. It is a waste of time
and
space to run the rest of the values through the lookup. The overhead is
pretty immense. Best I can tell the compile size of InitiaizeComponents()
+
default resouce is approximately 5 times larger with than without
localization.

I took a 1.8 meg UI intensive DLL, turned all these flags on which
resulted
in a DLL that was 5.4 megs.

Any advice appreciated. Thanks.