【问题标题】:String gets mysteriously cut off字符串被神秘地切断
【发布时间】:2011-11-08 20:44:20
【问题描述】:

在我的应用程序中,我使用WpfLocalization 在应用程序运行时提供翻译。该库基本上会维护一个属性列表及其分配的本地化关键字,并在活动语言更改时使用DependencyObject.SetValue() 更新其值。

我注意到我的问题的场景是:我有一个简单的TextBlock,并为其Text 属性分配了一个本地化关键字。现在,当我的应用程序启动时,它会将初始值写入其中,并且它会在屏幕上正常显示。现在我切换语言并将新值设置为Text 属性,但实际上只有一半文本会显示在屏幕上。来回切换语言没有任何效果。第一种语言总是显示得很好,第二种语言被截断(在单词中间,但总是完整的字符)。

这两种语言的相对长度似乎与此无关。在我的测试用例中,工作语言字符串是 498 字节,被截断的是 439 字节,在 257 字节后被截断)。

当我在通过本地化代码更改其值之前检查所述TextBlockText 属性的当前值时,无论哪种语言,它都将始终具有预期值(而不是截断)。

在运行时通过 WPF Inspector 检查 TextBlock 时,它会将截断的文本显示为第二语言的 Text 属性。

到目前为止,这对我来说毫无意义。不过现在好多了。

原始的 WpfLocalization 库从标准资源文件中读取本地化字符串,但我们使用修改后的版本,它也可以从 Excel 文件中读取这些字符串。它通过使用 Microsoft OLE DB 驱动程序打开一个OleDbConnection 并通过它读取字符串来做到这一点。在调试器中,我可以看到所有值都被读取得很好。

现在,当一位同事找到解决“截断文本”问题的方法时,我感到非常惊讶。他对 Excel 工作表中的行重新排序。我看不出这有什么关系,但是在该文件的两个版本之间切换会对问题产生影响。

【问题讨论】:

    标签: c# .net wpf localization oledb


    【解决方案1】:

    这确实是有道理的,这是因为 Excel 的 ole db 驱动程序必须对列中的数据进行采样,以便为其分配一个类型,如果是字符串,还需要一个长度。如果它只对低于 255 个字符阈值的值进行采样,您将获得一个 string(255) 类型和截断的文本,如果它采样了一个较长的字符串,它会将其分配为一个备忘录列并允许检索/存储更长的字符串。通过重新排序,您可以更改采样的行。

    如果您使用 oledb 将 SQL Server 读取到 Excel,您会发现这是一个已知问题。 http://msdn.microsoft.com/en-us/library/ms141683.aspx - 由于您使用的是相同的 ole db 驱动程序,我希望这种情况也适用于您。

    来自文档:

    截断的文本。 当驱动程序确定一个 Excel 列 包含文本数据,驱动选择数据类型(字符串或备忘录) 基于它采样的最长值。如果司机不 在它的行中发现任何超过 255 个字符的值 示例,它将列视为 255 个字符的字符串列 的备忘录列。因此,超过 255 个字符的值可能是 截断。要在不截断的情况下从备注列导入数据,您 必须确保至少有一个样本中的备忘录列 rows 包含超过 255 个字符的值,或者您必须增加 驱动程序采样的行数以包括这样的行。你 可以通过增加的值来增加采样的行数 TypeGuessRows 下 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel 注册表 钥匙。有关详细信息,请参阅 PRB:从 Jet 4.0 传输数据 OLEDB 源失败并出现错误。

    【讨论】:

    • 现在很有意义。但是为什么我在调试器中看到了完整的字符串呢?
    猜你喜欢
    • 1970-01-01
    • 2011-05-19
    • 2017-08-07
    • 2020-02-29
    • 1970-01-01
    • 1970-01-01
    • 2018-10-15
    • 2023-03-07
    • 1970-01-01
    相关资源
    最近更新 更多