Блог

В моем приложении я использую WpfLocalization для предоставления переводов во время работы приложения. Библиотека в основном будет поддерживать список свойств и назначенных им ключевых слов локализации и использовать DependencyObject.SetValue() для обновления их значений при изменении активного языка.

Сценарий, в котором я заметил свою проблему, заключается в следующем: у меня есть простое TextBlock и назначенное ключевое слово localization для его Text свойства. Теперь, когда мое приложение запускается, оно запишет в него начальное значение, и оно будет отлично отображаться на экране. Теперь я переключаю язык, и новое значение устанавливается в качестве Text свойства, но на самом деле на экране будет отображаться только половина текста. Переключение языков взад и вперед не имеет никакого эффекта. Первый язык всегда отображается нормально, второй обрезается (в середине слов, но всегда полными символами).

Относительная длина обоих языков друг к другу, похоже, не имеет к этому никакого отношения. В моем тестовом примере строка рабочего языка составляет 498 байт, а та, которая обрезается, составляет 439 байт и обрезается через 257 байт).

Когда я проверяю текущее значение Text свойства said TextBlock прямо перед тем, как изменить его значение с помощью кода локализации, оно всегда будет иметь ожидаемое значение (не обрезанное) на любом языке.

При проверке текстового блока во время выполнения с помощью инспектора WPF он отобразит обрезанный текст как свойство Text на втором языке.

Пока это не имеет для меня никакого смысла. Но теперь все становится лучше.

Оригинальная библиотека WpfLocalization считывает локализованные строки из стандартных файлов ресурсов, но мы используем модифицированную версию, которая также может считывать эти строки из файла Excel. Это делается путем открытия OleDbConnection с помощью драйвера Microsoft OLE DB и чтения строк через него. В отладчике я вижу, что все значения считываются просто отлично.

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

Это действительно имеет смысл, потому что драйвер ole db для Excel должен взять выборку данных в столбце, чтобы присвоить ему тип, а в случае строки — также длину. Если он выбирает только значения ниже порогового значения в 255 символов, вы получите тип string (255) и усеченный текст, если он выбрал более длинную строку, он назначит ее в качестве столбца memo и разрешит извлекать / сохранять более длинные строки. Изменяя порядок, вы меняете, какие строки выбираются.

Если вы прочитаете SQL Server в Excel с использованием oledb, вы обнаружите, что это известная проблема. http://msdn.microsoft.com/en-us/library/ms141683.aspx — поскольку вы используете тот же драйвер ole db, я бы ожидал, что ситуация также применима к вам.

Из документов:

Усеченный текст. Когда драйвер определяет, что столбец Excel содержит текстовые данные, драйвер выбирает тип данных (строка или памятка) на основе самого длинного значения, которое он выбирает. Если драйвер не обнаруживает никаких значений длиной более 255 символов в строках, которые он выбирает, он обрабатывает столбец как столбец из 255 символов, а не как столбец memo. Следовательно, значения длиной более 255 символов могут быть усечены. Чтобы импортировать данные из столбца memo без усечения, вы должны убедиться, что столбец memo по крайней мере в одной из выбранных строк содержит значение длиной более 255 символов, или вы должны увеличить количество строк, выбранных драйвером, чтобы включить такую строку. Вы можете увеличить количество выборочных строк, увеличив значение TypeGuessRows в разделе реестра HKEY_LOCAL_MACHINESOFTWARE Microsoft Jet 4.0 Engines Excel. Для получения дополнительной информации см. PRB: Передача данных из источника Jet 4.0 OLEDB завершается ошибкой.