WinRes

Article
08/21/2003

WinRes is
a .Net SDK tool that localization specialists can use to localize Forms. It hosts
designers for the Form and components on it, and also a property grid, using which
you can localize a Form and save it to the appropriate culture. The MSDN link above
has general information about how to use this tool.

The cool thing about WinRes is that it can visually represent a Form based on just
the information contained in a resource file (.resx or .resources). It can bring up
a Form at design time and allow you to modify its localizable properties - all without
access to the source code. How does it do that? The resource file has information
in it about the Type of the components present on a Form. WinRes uses this information
to dynamically create those components and their designers. It then initializes the
(Localizable) properties on those components using the values serialized (I will probably
talk another day about how we do the serialization) into the resource file by Visual
Studio. Once the localizer has made the appropriate modifications, it serializes the
new set of property values into a culture specific resource file (like Form1.fr.resx
for French) that can be built into a satellite assembly. To learn more about Localization
in general, here are
some useful articles.

The ability to design and localize a Form visually without access to the source code
is nice, but there are currently some limitations to what WinRes can do. I have fielded
many questions about WinRes from both internal and external customers. I think documenting
the limitations of the WinRes and the common issues you might run into maybe of some
benefit. This blog is as good a place as any to do this, so here goes.

WinRes TroubleShooting

First of all, having a basic knowledge of the resource file format can be extremely
useful when you run into problems. Resource files can be either in XML (.resx) or
binary (.resources) format. The .resx format is more human-readable, so if you have
a .resources file that you wish to look at, use the ResGen tool
to convert it to a .resx. Now, open the .resx file in notepad. You will find the schema
definition and some other stuff in the header. That stuff is not so interesting, so
I won't describe it here. The rest of the .resx file is made up of "data" nodes. Each
data node represents one localizable property in the dialog. Lets look at a couple
of data nodes in a simple resx file for a Form that contains a Button:

</data>

<value>button1</value>

</data>

The first node has the name "button1.Size", so looks like it represents the Size property
of a component called button1. The type attribute represents, not surprisingly, the
full name of the Type of this property. The value node contains a string representation
of value of the Size property, which is in this case: (Width = 75, Height = 23). SImilarly,
the second node above represents the Text property on button1. There is no Type information,
so by default, this means that the property is of type String.

Okay, but what is button1? This information is conveyed by the following "special"
properties, prefixed with the ">>":

<data name=">>button1.Name">

<value>button1</value>

</data>

<data name=">>button1.Type">

<value>System.Windows.Forms.Button, System.Windows.Forms,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>

</data>

<data name=">>button1.Parent">

</data>

<data name=">>button1.ZOrder">

</data>

These are special because they convey information about what button1 represents. The
Type property tells us that button1 is actually a Windows Forms Button control. Its
parent is "$this", which represents the Form being localized. The ZOrder value helps
determine the order in which this component is placed on this Parent control relative
to its siblings. The Name, ofcourse, is the name assigned to this instance of the
Button control by the VS designer. With the above information, you should be able
to decipher most of the contents of the .resx file.

Okay, now we are ready to look at some of the possible reasons for getting a 'Red
X' (error) in WinRes when you load a Form. Unfortunately, the error messages that
WinRes displays are currently often cryptic. So, when an error occurs, you should
open the .resx file in notepad and take a look.

- The most common problem is due to a current limitation of WinRes that it needs to be able to instantiate all the components on the Form. To instantiate a particular component, WinRes needs to load the assembly that contains it. WinRes needs the assembly to be present either in the Global Assembly Cache (GAC) or the same folder as WinRes.exe (search your file system for this file to locate where WinRes.exe is present - its usually in [dir where VS is installed]\SDK\[version]\Bin. All the framework assemblies should be in the GAC already, so WinRes should be able to instantiate components in them. However, if you have user controls or third party controls on your Form and their assemblies aren't in the GAC, you should either install them in the GAC or copy them to the WinRes folder.

Make sure that controls with a common parent have unique "ZOrder" values. If two or  
more controls with a common parent have the same ZOrder, WinRes is likely to fail  
to load the dialog, since it doesn't know in what order to place the controls.

Sometimes, the resx may contain incorrect Type information for one or more of the
components in the Form. Make sure that the Type's name and assembly information is
correct and complete. If not, WinRes will fail to load the Type.
The "name" attribute represents a property on a component and is always of the form
"component.Property" (with the exception of the ">>" prefix on the special properties).
Make sure that the names in your resx are in that format. Also, make sure that all
the 4 special properties noted above are present for each component. WinRes needs
those!
Make sure you are using the version of WinRes compatible with the assemblies you are
localizing. For example, if your assemblies are built against v1.1 of the .NET Framework,
use the WinRes.exe that came with v1.1 framework SDK. If not, you might run into weird
versioning issues.
Another issue you might run into is this: when you have a combobox or listbox with
items in it and you bring up the dialog with this control in WinRes, WinRes may not
populate the control with those items. Further, if you add items to it through WinRes
and save the localized resource, the localized items will not get picked up at runtime.
It is, unfortunately, a limitation in WinRes currently that it is not able to handle
collections (like the comboBox.ItemsCollection) correctly. The workaround is to not
pre-populate the control with items, but do so at runtime with localized strings.

That is all I can think of at this time. I will post more information when I can.

Comments

Anonymous
November 24, 2005
Hi Prabhu,

Though I am too late too read your article as its posted way back in 2003.

Any start is a good start in learning..

So read your article..Pretty good..Well collected material. And also quite different from what I have seen in few others.

Keep Posting Good Articles.

Regards

Kunal shah
kunalshah83@gmail.com
Anonymous
November 25, 2005
Thanks Kunal - glad you found it useful.
Anonymous
January 07, 2006
Hi,

Why the type is stored in the resource file? It seems quite silly!

And now, if you have localized form in .Net 1.1 how you will open in .Net 2.0 Forms designer? You cannot.

Have you considered those issues? How do you suppose all the localized forms in 1.1 willbe migrated to 2.0? Manually?

Regards,

Veselin
Anonymous
January 18, 2006
You can open v1.1 localized forms in v2.0 form designer in VS. VS has a specialized type resolution implementation that will resolve the types correctly. Once you make a change to a form, the resx will automatically be updated to v2.0 references.

As for WinRes, it is recommended to use the same version of WinRes.exe as the .NET version you are targeting.
Anonymous
June 05, 2006
The comment has been removed
Anonymous
June 07, 2006
Larry: You should be able to use the ResXResourceReader and ResXResourceWriter classes to process resx files. Regarding the special '>>' properties, I don't know if they are documented, but I think third party software already exists today that depend on it. I would recommend logging a bug in MSDN Product Feedback to request that they be documented (if not already).
Anonymous
June 13, 2006
Hi Prabhu,

Thanks very much for the feedback. I don't believe those symbols are documented after a painstaking search so will contact MSDN Product Feedback as you suggested. Thanks again.
Anonymous
June 14, 2006
Hi Prabhu,

One other important question for you if you don't mind. I just read your other blog entitled "How does the Windows Forms designer in Visual Studio load a Form" (currently at http://blogs.msdn.com/rprabhu/archive/2004/12/12/280823.aspx) and am now unsure if the approach I suggested earlier is correct. Note that I'm fairly new to .NET but otherwise a very experienced C/C++ developer (20+ years on MSFT platforms and very comfortable with C#). In a few sentences or less since I don't want to take too much of your time (I can do the leg work), could you simply point me in the "right" direction for doing the following. I'm writing an Add-In that needs to pull out all localized forms in a solution and bundle them up so they can be displayed elsewhere (for viewing purposes only on machines without Visual Studio present). Is it appropriate to simply bundle up all localized (form-based) ".resx" files accordingly and ship them out. My app will then re-generate these forms based on this ".resx" info. Or should I be investigating "CodeDomProvider" and cousins as you discussed in the above link. Or should I be using reflection to find and gather up all forms in the solution. I'm really not sure which method (or hybrid thereof) would be recommended and some guidance would be greatly appreciated (I've done lots of research already). Also note that when "InitializeComponent()" is created in the IDE, it automatically sets certain other (non-localized) properties in-code such as "UseVisualStyleBackColor" on button controls. How would I then know to do this myself if, say, I simply re-generate the form using the bundled ".resx" files approach (akin to what "WinRes.exe" does). Again, your assistance would be greatly appreciated (I can't find adequate info elsewhere after a painstaking search). Thanks again.
Anonymous
June 14, 2006
Sorry Raghavendra, but I just realized I've been addressing you by your last name (mea culpa). My apologies :)
Anonymous
June 19, 2006
Larry: In general, I would say simply enumerating the resx files in the solution and using them should work. After all, WinRes too only has the resx files to work with, and does not have know about any other changes that might be in InitializeComponent. The theory is that any changes relevant to localization should be in the resx anyway, so other changes in code should not matter to localizers.

Note though that your resx parser tool will need access to the assemblies/types referenced in the resx, just like WinRes, in order to instantiate them.

Anyway, I must mention that I have moved to a different team in Microsoft around 8 months ago, so I am quite out of touch with this stuff. I am not sure who the current owner of WinRes is, but you could start by contacting Brad Abrams (blogs.msdn.com/brada), who might be able to point you to the right person.
Anonymous
June 21, 2006
Ok, your comments make me more comfortable that at least I'm on a suitable path (it's always reassuring to have someone on the inside help validate things). I'll contact Brad Adams as suggested however just in case there's a better way to do this now (a new class perhaps). Thanks for the feedback (appreciated).
Anonymous
July 07, 2006
The comment has been removed
Anonymous
July 11, 2006
The comment has been removed
Anonymous
July 28, 2006
Thanks for the feedback (sorry for the delay responding). Unfortunately, reflecting over the assemblies doesn't appear to be viable since the programmer may have added additional code after the call to "InitializeComponent()". This code may not be runnable in the development environment (or is potentially unsafe to run there) so it can't be relied on. Parsing "InitializeComponent()" isn't viable either for the reasons you mentioned and a programmer would have to write their own language parser anyway (which isn't feasible as you noted). The only way I can think of is to perhaps copy "InitializeComponent()" into a temporary ".cs" file on the fly (using some temporary class), and then I can compile and run it. This is unwieldy however (and incredibly ugly) but there doesn't appear to be any other option. I think the situation is something that should be addressed by MSFT however even if relatively few developers actually require this functionality. It may be low priority but the programming model remains incomplete IMO. There's simply no clean way to extract a complete form from a project but it should be relatively easy to add this functionality and I already made my own recommendations to product feedback several weeks ago (on the surface it should be doable with no backward compatibility issues). Anyway, unless you have any other last suggestions, thanks again for all your help (appreciated).
Anonymous
February 16, 2007
The comment has been removed
Anonymous
February 17, 2007
Yayu: I think WinRes was designed to cover the basic and common localization scenarios. For more advanced stuff, there are good third party tools available as well. That said, if you have any feedback or suggestions, please submit it through the MSDN Product Feedback page so it can be tracked properly (I am no longer working in this area). Thanks!
Anonymous
January 18, 2009
PingBack from http://www.keyongtech.com/2324296-why-name-parent-type-and

Partager via

WinRes

Comments

Ressources supplémentaires