Resources in project file in VS2008 gets “reused” creatively by the form designer, possible to avoid?

Question

We have some auto-generated resource files in our project in Visual Studio 2008, with some localized versions, and in one of these localized versions, there is a string which in this case is empty.

More explicit. We have a core resource file, with lots of string resources. We then have 4 other localized versions of thisfile, and in one of these other localized files, one of the strings is given an empty value.

The problem now is that the form designer is quite happy about having found a resource for a string, and will apparently stop at nothing for reusing this resource for any empty strings it will assign a property in the generated designer code for a form.

For instance, if for some reason a property on a control is not specified with a default value (so it will be serialized to code even if it is empty), then it will reference our resource instead of writing out the empty string literal in the C# code.

Problem is that it references the localized versions, and these aren't compiled to code.

Here's an abbreviated code example:

this.rpAllFields.KeyTip = 
  global::namespaces.SystemMessagesResources_sv_SE.
    dash_red_shift_info_description;

In this case, the dash_red_shift_info_description does not have a value for the sv-SE locale, so the designer, when it sees an empty string in the code, will try to link to that resource. But the SystemMessagesResources_sv_SE isn't an existing class, but seemingly a generated class name for the swedish localized version of the SystemMessagesResources resource file, which is compiled to a class.

Is this possible to avoid? We're getting rather tired of the search/replace each time we change something in the form files, and we're pretty sure there's a slap-my-forehead-boneheaded thing we've done that make this happens, but we're aparently not capable of finding the cause of this ourselves.

The above code would, if we removed the resource, read like this:

this.rpAllFields.KeyTip = "";

Answer 1

You might try creating a string resource empty_string, defined as "" for every locale. If you make it the first resource, the form designer will (hopefully) always pick that one as the value to sprinkle through your forms. This way at least you'll be using a string designated for that purpose.

Answer 2

If the problem is being caused by an empty string in the resource file, what would the effect be of making it a space. So instead of "" the resource file contains " ". I don't know if that's the best solution but I would be interested to know if it stops the designer from using that resource as a default empty string. However, not knowing how it is used, I'm not sure what the impact of having a value that should be undefined be defined as a space...

Answer 3

How much do you need a resource whose value is an empty string? I can imagine some multilingual scenarios where some resource key should correspond to blank in some of the supported languages (if you are using string concatenation for some UI elements), yes.

But if MY scenario wasn't something like this, I would just scrap the resource entry with the empty string. I'd just say, "What standalone UI text translates to blank, anyway?".

If I really needed the resource to be blank in some cases, (where it stands for an article in one language and where no equivalent word exists in another), I would try to see if I could produce the same effect some other way.

Answer 4

Generated resource file and code sample would be good.

And what you are saying is: you have an empty string literal definition in your namespace (the first one found) but that is causing some problem? Won't it be empty at all times? When you compile the code- it does quirky things like this to save space. I ran into a similar issue when generating XAML files with codebehind for on-the-fly automated build of assembly files: The compiler is smart enough to know 'it doesn't make a difference but for us it did because it would rename the literals (which were used elsewhere).

To work around this we used named types for these primitives in our namespace and made that one global. What I see here is that your global namespace is filling in the blanks- you may want to have one 'below' which evaluates all null strings.

I haven't worked with this in over a year so forgive me if my wording is poor, but what i mean is: think XML. You need to either explicitly use namespace in the properties or assign them lower (like attached property in xaml).

I hope this helps (and makes sense)