Ресурсы в файле проекта в VS2008 творчески "повторно" используются дизайнером форм, можно избежать?

У нас есть несколько автоматически сгенерированных файлов ресурсов в нашем проекте в Visual Studio 2008 с некоторыми локализованными версиями, и в одной из этих локализованных версий есть строка, которая в данном случае пуста.

Более явный У нас есть файл основных ресурсов с большим количеством строковых ресурсов. Затем у нас есть 4 другие локализованные версии этого файла, и в одном из этих других локализованных файлов одна из строк получает пустое значение.

Проблема в том, что дизайнер форм очень доволен тем, что нашел ресурс для строки, и, очевидно, не остановится на повторном использовании этого ресурса для любых пустых строк, он назначит свойство в сгенерированном коде конструктора для формы.

Например, если по какой-то причине свойство элемента управления не указано со значением по умолчанию (поэтому оно будет сериализовано в код, даже если оно пустое), оно будет ссылаться на наш ресурс, а не записывать пустой строковый литерал в Код C#

Проблема в том, что он ссылается на локализованные версии, а они не скомпилированы в код.

Вот сокращенный пример кода:

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

В этом случае dash_red_shift_info_description не имеет значения для локали sv-SE, поэтому дизайнер, увидев в коде пустую строку, попытается связаться с этим ресурсом. Но SystemMessagesResources_sv_SE не является существующим классом, а, по-видимому, сгенерированным именем класса для шведской локализованной версии файла ресурсов SystemMessagesResources, который компилируется в класс.

Можно ли этого избежать? Мы довольно устали от поиска / замены каждый раз, когда что-то меняем в файлах форм, и мы почти уверены, что мы сделали что-то пощечину, что сделали это, но мы видимо, не в состоянии найти причину этого сами.

Код выше, если мы удалим ресурс, будет выглядеть так:

this.rpAllFields.KeyTip = "";
Источник

4 ответа

Решение

Вы можете попробовать создать строковый ресурс empty_string, определенный как "" для каждой локали. Если вы сделаете его первым ресурсом, дизайнер форм (будем надеяться) всегда выберет его в качестве значения для разбрызгивания ваших форм. Таким образом, по крайней мере, вы будете использовать строку, предназначенную для этой цели.

Источник

Если проблема вызвана пустой строкой в ​​файле ресурсов, каков будет эффект, сделав его пробелом. Таким образом, вместо "" файл ресурсов содержит " ". Я не знаю, является ли это лучшим решением, но мне было бы интересно узнать, не мешает ли он использовать этот ресурс в качестве пустой строки по умолчанию. Тем не менее, не зная, как это используется, я не уверен, какой эффект от наличия значения, которое должно быть неопределенным, можно определить как пробел...

Источник

Насколько вам нужен ресурс, значением которого является пустая строка? Я могу представить несколько многоязычных сценариев, где некоторый ключ ресурса должен соответствовать пробелу в некоторых из поддерживаемых языков (если вы используете конкатенацию строк для некоторых элементов пользовательского интерфейса), да.

Но если бы в моем сценарии не было ничего подобного, я бы просто отбросил запись ресурса с пустой строкой. Я бы просто сказал: "Какой текст автономного интерфейса переводится как пустой?".

Если бы я действительно хотел, чтобы ресурс был пустым в некоторых случаях (где он обозначает статью на одном языке, а эквивалентное слово не существует на другом), я бы попытался выяснить, смогу ли я получить такой же эффект другим способом.

Источник

Сгенерированный файл ресурса и пример кода будут хорошими.

И что вы говорите: у вас есть пустое строковое литеральное определение в вашем пространстве имен (первое найденное), но это вызывает некоторую проблему? Не будет ли он всегда пустым? Когда вы компилируете код, он делает такие причудливые вещи, чтобы сэкономить место. Я столкнулся с подобной проблемой при создании файлов XAML с codebehind для автоматической сборки файлов сборки на лету: компилятор достаточно умен, чтобы знать: "это не имеет значения, но для нас это произошло, потому что он переименовал бы литералы". (которые были использованы в другом месте).

Чтобы обойти это, мы использовали именованные типы для этих примитивов в нашем пространстве имен и сделали его глобальным. То, что я вижу здесь, это то, что ваше глобальное пространство имен заполняет пробелы - вы можете захотеть иметь одно "ниже", которое оценивает все пустые строки.

Я не работал с этим больше года, так что извините, если моя формулировка плохая, но я имею в виду: думаю, XML. Вам нужно либо явно использовать пространство имен в свойствах, либо присвоить им более низкие значения (например, прикрепленное свойство в xaml).

Я надеюсь, что это помогает (и имеет смысл)

Источник
Другие вопросы по тегам