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

StackOverflow https://stackoverflow.com/questions/435466

Вопрос

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

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

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

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

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

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

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 = "";
Это было полезно?

Решение

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

Другие советы

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top