Каскадные списки, использующие SPFieldMultiChoice - по умолчанию используется тип содержимого по умолчанию

Question

Я закончил модификацию источника из общедоступного POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx,, который является определением настраиваемого поля для каскадных выпадающих списков. Изменения заключались в том, чтобы разрешить родительские списки со списками, где пользователь может выбрать несколько элементов для фильтрации и выбора значений для записи обратно в список SharePoint. У меня работает каскадное поведение «родитель-потомок», но операция сохранения принимает только значение типа содержимого по умолчанию.

Я изменил базовый тип для элемента управления настраиваемого поля с «SPFieldText» на «SPFieldMultiChoice», а также изменил значения определения поля FLD_TYPES с: «Text» на «MultiChoice»

объясненные шаги: 1. Создается настраиваемое поле, производное от класса «SPFieldMultiChoice». В настраиваемом поле можно выбрать несколько значений. 2. Поле, созданное с использованием указанного выше настраиваемого поля, добавляется к настраиваемому типу контента, созданному из графического интерфейса, полученного из типа контента «Документ». 3. Пользовательский тип контента добавляется в библиотеку документов. 4. Документ загружен, и пользовательский тип контента выбран и помечен для документа. О. Правильный тип содержимого помечается правильными метаданными, если тип документа - .xls, .doc, .txt и т. Д. B. Тип содержимого по умолчанию, т. Е. «Тип содержимого документа», помечается тегом, если тип документа - .xlsx, .docx.

Сводка проблемы - Точка # B: это проблема, поскольку правильный тип контента не помечен, а тип контента по умолчанию помечен, если тип загруженного документа - .xlsx или .docx. Однако тот же тип содержимого, то же настраиваемое поле работает, если тип документа - .xls или .doc.

Ценю ваш вклад в этом отношении.

Спасибо, что нашли время, чтобы прочитать мой пост.

Приветствия, ~ Poonam

Answer 1

Не уверен, почему это происходит, было бы неплохо уведомить Microsoft об этом поведении. Описанная вами разница между .doc и .docx очень и очень странная. Не могли бы вы попытаться установить тип содержимого в itemeventreceiver, чтобы заставить поля ContentType или ContentTypeId элемента явно отражать правильный тип содержимого.

т.е.

item["ContentTypeId"] = new ContentTypeId("0x010100your_id_plus_the_part_added_by_list");

the_part_added_by_list - это дополнительный guid, который добавляется при добавлении ctype в список это потому, что ctypes в списке в основном являются потомками фактического ctype, который вы добавили

т.е. 0x010100 YOURGUID 00 LIST SPECIFIC GUID,

Вы можете получить этот полный идентификатор, используя такой инструмент, как Stramit CAMLViewer или progr. циклически просматривая коллекцию ContentTypes в SPLIst.

(мое предположение должно было бы сделать это в событии ItemUpdating / ItemUpdated, чтобы увидеть, есть ли разница в ctype во время этих вызовов)