Установка MetaProperty для типа поиска приводит к сбою MS Word - PullRequest
Новая
       6

Установка MetaProperty для типа поиска приводит к сбою MS Word

2 голосов
/ 10 февраля 2011

У нас есть надстройка VSTO, написанная на VB.Net 3.5 и работающая в MS Word 2010. В этой надстройке VSTO мы установили ряд мета-свойств SharePoint (2010), которые возвращаются из коллекции документов ContentTypeProperties.

Иногда (довольно регулярно, но не всегда), когда мы устанавливаем свойство Value элемента MetaData, имеющего тип msoMetaPropertyTypeLookup, это приводит к сбою Word. Очевидно, есть попытка поймать настройку значения, но она не исключение - Word просто умирает. Подробная информация об ошибке Word приведена ниже, но я подозреваю, что она никому не поможет. Для полей, имеющих тип text, нет необходимости устанавливать их значения.

Было бы очень признательно, если бы кто-то смог указать нам правильное направление, чтобы всегда иметь возможность устанавливать значение свойства метаданных поиска таким образом, чтобы не убивать слово!

Также у нас есть одно свойство 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

Ответы [ 2 ]

2 голосов
/ 04 декабря 2012

У меня была та же проблема, и я обнаружил в Схеме ContentTypeProperties *1002*, что у внутренних имен полей в конце был 0, как у CustomSiteColumnName0, однако у имени поля нет.Это произошло из-за того, что тип контента имел собственный родительский тип контента, который также имел некоторые столбцы сайта, но у этих столбцов были хорошие внутренние имена в SchemaXml.

Так что, к счастью, после удаления столбцов из родительского типа контента, к счастьюЯ не использовал их вообще, все просто начало работать правильно в новом документе, основанном на пользовательском типе контента.

0 голосов
/ 05 апреля 2011

Я пытался сделать то же самое в VBA и столкнулся с той же ошибкой, просто перечисляя свойства из документа, размещенного на sharepoint. 

Sub GetDocProps()

    Dim i As Long
    Dim prop As Office.MetaProperty
    Dim props As Office.MetaProperties

    Set props = ActiveDocument.ContentTypeProperties
    i = 1
    For Each prop In props
        ' Debug.Print i & ". Type: " & prop.Type & " ID: " & prop.ID & " Name: " & prop.Name & " Value: " & prop.Value
        Debug.Print i & "." & " ID: " & prop.ID & " Name: " & prop.Name
        i = i + 1
    Next prop
End Sub

Сбой при работе 9-го свойства с идентификатором Intern_x002f_extern и именем столбца «Internal from External Created» Также существует столбец с именем «Afzender / Geadresseerde»

Это было семейство сайтов, созданное некоторыми внешними консультантами. Поэтому я думаю, что эти консультанты не следовали правилам, используя недопустимые символы (т.е. /) в имени столбца.

Нарушение этих правил дает всевозможные неприятные побочные эффекты.

Так что остерегайтесь использования неправильных имен столбцов и не алфавитно-цифровых имен в sharepoint. Вы в конечном итоге выстрелите себе в ногу.

С уважением

Marcel

...