The string becomes mysteriously cut off

Question

In my application, I use WpfLocalization to provide translation while the application is running. The library will mainly maintain a list of properties and its localization keywords and use DependencyObject.SetValue() to update its values ​​when the active language changes.

The scenario in which I noticed my problem is this: I have a simple TextBlock and a localization keyword is assigned to its Text property. Now, when my application starts, it will write the initial value into it, and it will only be displayed on the screen. Now I switch the language, and the new value is set as the Text property, but only half of the text will actually be displayed on the screen. Switching languages ​​back and forth has no effect. The first language is always displayed well, the second is cut off (in the middle of words, but always full characters).

The relative length of both languages ​​to each other does not seem to have anything to do with this. In my test example, the working language string is 498 bytes, and the one that is truncated is 439 bytes and truncated after 257 bytes).

When I check the current value of the Text property of the specified TextBlock right before changing its value through the localization code, it will always have the expected value (not interrupted) in any language.

When checking a TextBlock at run time through the WPF Inspector, it will display the cut text as a Text property in the second language.

It makes no sense to me so far. But now it’s getting better.

The original WpfLocalization library reads localized lines from standard resource files, but we use a modified version, which can also read this line from an Excel file. He does this by opening OleDbConnection using the Microsoft OLE DB driver and looking at the rows. In the debugger, I see that all values ​​are read just fine.

Now I was very surprised when a colleague found a fix for the subject "cut text". He reordered the rows in an Excel worksheet. I do not see how this may be relevant, but the transition between the two versions of this file affects the problem.

Answer 1

This really makes sense, because the ole db driver for Excel needs to take a sample of the data in the column in order to assign it a type, and in the case of a row, also the length. If it only displays values ​​below the threshold of 255 characters, you will get a row type (255) and truncated text, if it tried a longer row, it will assign it as a memo column and allow longer lines to be extracted / saved. By reordering, you change which rows are selected.

If you read SQL Server in Excel using oledb, you will find that this is a known issue. http://msdn.microsoft.com/en-us/library/ms141683.aspx - since you are using the same ole db driver, I would expect the situation to apply to you as well.

From the docs:

Truncated text. When the driver determines the Excel column contains text data, the driver selects the data type (row or memo) based on the longest value that it displays. If the driver does not find values ​​in the rows that exceed 255 characters in the patterns, it treats the column as a column of a row with 255 characters instead of a note column. Therefore, values ​​greater than 255 characters can be truncated. To import data from a note column without truncating, you must make sure that the note column in at least one of the sample rows contains a value exceeding 255 characters, or you must increase the number of rows selected by the driver to include such a row. You can increase the number of rows selected by increasing the TypeGuessRows value under the HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Jet \ 4.0 \ Engines \ Excel registry key. For more information, see PRB: Data Transfer with Jet 4.0 OLEDB Source Error with Error.