打开 XML 文档 ContentControls 与签名 ID 的问题

发布于 2024-08-29 21:20:16 字数 858 浏览 3 评论 0原文

我有一个使用内容控件生成 Open XML 文档的应用程序。

为了创建新的内容控件,我使用 Interop 和方法 ContentControls.Add。此方法返回添加的内容控件的实例。

我有一些逻辑可以保存内容控件的 id 以便稍后引用它,但在某些计算机中我遇到了一个奇怪的问题。

当我访问刚刚创建的内容控件的 ID 属性时,它返回一个带有数字 id 的字符串,问题是当这个值太大时,在我保存文档后,如果我查看 文档。在生成的文档的 xml 中, 元素的 元素具有负值,这是我从生成的控件的 Id 属性中获取的值的带符号等效项。

例如:

var contentControl = ContentControls.Add(...);
var contentControlId = contentControl.ID;
// the value of contentControlId is "3440157266"

如果我保存文档并在 Package Explorer 中打开它,则内容控件的 Id 为“-854810030”而不是“3440157266”。

我想到的是:

((int)uint.Parse("3440157266")).ToString()  returns "-854810030"

知道为什么会发生这种情况吗?这个问题很难复制,因为我不控制生成的控件的IdId是由Interop库自动生成的。

I have an application that generates Open XML documents with Content Controls.

To create a new Content Control I use Interop and the method ContentControls.Add. This method returns an instance of the added Content Control.

I have some logic that saves the id of the Content Control to reference it later, but in some computers I've been having a weird problem.

When I access the ID property of the Content Control I just created, it returns a string with the numeric id, the problem is that when this value is too big, after I save the document, if I look through the document.xml in the generated document, the <w:id/> element of the <w:sdtPr/> element has a negative value, that is the signed equivalent of the value I got from the Id property of the generated control.

For example:

var contentControl = ContentControls.Add(...);
var contentControlId = contentControl.ID;
// the value of contentControlId is "3440157266"

If I save the document and open it in the Package Explorer, the Id of the Content Control is "-854810030" instead of "3440157266".

What have I figured out is this:

((int)uint.Parse("3440157266")).ToString()  returns "-854810030"

Any idea of why this happens? This issue is hard to replicate because I don't control the Id of the generated controls, the Id is automatically generated by the Interop libraries.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

硬不硬你别怂 2024-09-05 21:20:16

当以32位二进制格式显示时,-854810030和3440157266是一样的!

When displayed in 32-bit binary format, -854810030 and 3440157266 are just the same!

岁吢 2024-09-05 21:20:16

MSDN 文档中提到了这个问题 ContentControl.ID 属性

当您在运行时获取 ID 属性值时,它将作为无符号值返回。但是,当保存为 Office Open XML 文件格式时,它会保存为带符号的值。如果您的解决方案尝试将以编程方式返回的值映射到以文件格式保存的值,则必须检查从此属性获取的值的无符号和有符号版本。

正如 Claude Martel 提到的,-854810030 和 3440157266 是相同的。您可以通过将有符号的 Int32 转换为无符号的 UInt32 来轻松检查这一点:

var id = Convert.ToInt32("-854810030 ");
UInt32 uId = (uint) id;

Assert.AreEqual(3440157266, uId);

This problem is mentioned in the MSDN documentation of the ContentControl.ID Property:

When you get the ID property value at runtime, it is returned as an unsigned value. However, when saved into the Office Open XML file format, it is saved as a signed value. If your solution attempts to map programmatically returned values to values saved in the file format, you must check for both the unsigned and signed version of the value obtained from this property.

As Claude Martel mentioned, -854810030 and 3440157266 are ident. You can easily check this by casting the signed Int32 to a unsigned UInt32:

var id = Convert.ToInt32("-854810030 ");
UInt32 uId = (uint) id;

Assert.AreEqual(3440157266, uId);
握住我的手 2024-09-05 21:20:16

我过去也遇到过同样类型的问题。该 ID 不可靠,因为它似乎不会永久存在。相反,我所做的是存储内容控件的 .Tag 名称,以便我稍后可以访问它。

I've had the very same type of issue in the past. The ID is unreliable as it doesn't seem to perpeturate. What I did instead is stored a name of the Content Control's .Tag so I could access it later.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文