为查找类型设置 MetaProperty 会导致 MS Word 崩溃
我们有一个用 VB.Net 3.5 编写并在 MS Word 2010 中运行的 VSTO 外接程序。在此 VSTO 外接程序中,我们设置了从文档 ContentTypeProperties 集合返回的许多 SharePoint (2010) 元属性。
有时(经常,但并非总是)当我们设置 msoMetaPropertyTypeLookup 类型的元数据项的 Value 属性时,会导致 Word 崩溃。显然,在 Value 的设置周围有一个 try catch,但它没有捕获任何异常 - Word 就死了。有关 Word 错误的详细信息如下,但我怀疑它对任何人都没有多大用处。对于文本类型的字段,设置其值没有问题。
如果有人能够为我们指明正确的方向,以便始终能够以不会杀死单词的方式设置查找元数据属性的值,我们将非常感激!
此外,我们还有一个 MetaData 属性,它也是一种查找类型,但仅访问它的任何属性(例如值、名称、类型)会导致以下异常 “找不到元素。(HRESULT 异常:0x80070490)”
似乎不会导致此异常的唯一属性是 Id 属性。我能看到的唯一区别是字段名称中有一个正斜杠(“/”)。字段名称中的“/”无效吗?
默认 DIP 可以毫无问题地设置所有值。只是当我们尝试在代码中执行此操作时,我们才会遇到问题。
Problem signature:
Problem Event Name: APPCRASH
Application Name: WINWORD.EXE
Application Version: 14.0.5123.5000
Application Timestamp: 4c646b38
Fault Module Name: StackHash_6608
Fault Module Version: 6.1.7600.16695
Fault Module Timestamp: 4cc7ab44
Exception Code: c0000374
Exception Offset: 000c35e3
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 5129
Additional Information 1: 6608
Additional Information 2: 66081020834161d0adf96c6191f1a84c
Additional Information 3: fdd5
Additional Information 4: fdd5bad4f069a755d9154e340782caad
We have a VSTO add-in written in VB.Net 3.5 and running in MS Word 2010. In this VSTO add-in we set a number of SharePoint (2010) Meta Properties that are returned from the documents ContentTypeProperties collection.
Sometimes (quite regularly, but not all the time) when we set the Value property of a MetaData item that is of type msoMetaPropertyTypeLookup it causes Word to crash. Obviously there is a try catch around the setting of the Value, but no exception is caught by it - Word just dies. Details about the Word error is below, but I suspect it will not be much use to anyone. For fields that are of type text, there is no issue in setting their values.
It would be very much appreciative if someone was able to point us in the right direction to always be able to set the Value of a lookup metadata property in a way that doesn't kill word!
Also we have one MetaData property that is also a lookup type, but just accessing any of it's properties (such as value, name, type) causes the following exception
"Element not found. (Exception from HRESULT: 0x80070490)"
The only property that seems to not cause this exception is the Id property. The only difference I can see is that the name of the field has a forward slash in it ("/"). Is the "/" invalid in a field name?
The Default DIP can set all values without issues. It is just when we try and do it in code that we run into issues.
Problem signature:
Problem Event Name: APPCRASH
Application Name: WINWORD.EXE
Application Version: 14.0.5123.5000
Application Timestamp: 4c646b38
Fault Module Name: StackHash_6608
Fault Module Version: 6.1.7600.16695
Fault Module Timestamp: 4cc7ab44
Exception Code: c0000374
Exception Offset: 000c35e3
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 5129
Additional Information 1: 6608
Additional Information 2: 66081020834161d0adf96c6191f1a84c
Additional Information 3: fdd5
Additional Information 4: fdd5bad4f069a755d9154e340782caad
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我遇到了同样的问题,我在 ContentTypeProperties 架构 Xml 中发现字段的内部名称末尾有一个 0,例如
CustomSiteColumnName0
但字段的名称确实如此不是。这是因为内容类型有一个自定义父内容类型,该内容类型也有一些网站列,但这些列在 SchemaXml 中具有良好的内部名称。因此,从父内容类型中删除列后,幸运的是我根本没有使用它们,一切都开始在基于自定义内容类型的新文档中正常工作。
I had the same issue and I found in the ContentTypeProperties's Schema Xml that the internal names for the fields had a 0 at the end, like
CustomSiteColumnName0
however the name of the field did not. It was because of the content type had a custom parent content type that also had some site columns, but those columns had the internal names fine in the SchemaXml.So after removing the columns from the parent content type, fortunately I did not use them at all, everything just started to work properly in a new document based on the custom content type.
我在 VBA 中尝试了相同的操作,并在从共享点托管文档枚举属性时遇到了相同的错误。
它在带有 ID Intern_x002f_extern 且列名称为“Internal ot external Created”的第 9 个属性上崩溃
还存在一个名为“Afzender/Geadresseerde”的列,
这是由一些外部顾问构建的网站集。
所以我认为那些顾问没有遵守规则,在列名中使用非法字符(即
/
)。违反这些规则会带来各种令人讨厌的副作用。
因此,请注意在共享点中使用错误的列名称和非字母数字名称。
你最终会搬起石头砸自己的脚。
问候
马塞尔
I tried the same in VBA and encountered the same error just enumerating the Properties from a sharepoint hosted document.
It crashed on the 9th property carrying a ID Intern_x002f_extern and having a column name "Internal ot External Created"
Also there exist a column having a name "Afzender/Geadresseerde"
This was a Site collection which was constructed by some external consultants.
So I think those consultants did not follow the rules by using illegal characters (i.e.
/
) in column name.Breaking these rules gives all kinds of nasty side effects.
So beware of using bad column names and non-alphanumeric names in sharepoint.
You'll end up shooting yourself in your foot.
regards
Marcel