ListBox en cascade utilisant SPFieldMultiChoice - Valeurs par défaut des valeurs par défaut Type de contenu

Question

J'ai fini par modifier la source d'un POC publié publiquement: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, qui est une définition de champ personnalisée pour les listes déroulantes en cascade. Les modifications consistaient à autoriser les zones de liste parent-enfant où un utilisateur peut effectuer une sélection multiple pour le filtrage et sélectionner les valeurs à réécrire dans une liste SharePoint. Le comportement en cascade parent-enfant a fonctionné, mais l'opération de sauvegarde prend uniquement la valeur par défaut du type de contenu.

J'ai changé le type de base pour le contrôle de champ personnalisé de « SPFieldText » à « SPFieldMultiChoice », ainsi que la modification des valeurs de définition du champ FLD_TYPES de: « Texte » à « MultiChoice »

étapes Expliqué: 1. Le champ personnalisé créé est dérivé de la classe 'SPFieldMultiChoice'. Le champ personnalisé permet de sélectionner plusieurs valeurs. 2. Le champ Créé en utilisant le champ personnalisé ci-dessus est ajouté au type de contenu personnalisé créé à partir de l'interface graphique dérivée du type de contenu 'Document'. 3. Le type de contenu personnalisé est ajouté à la bibliothèque de documents. 4. Le document est téléchargé et le type de contenu personnalisé est sélectionné et étiqueté pour documenter. A. Le type de contenu correct est étiqueté avec les métadonnées correctes si le type de document est .xls, .doc, .txt, etc. B. Le type de contenu par défaut 'Type de contenu de document' est marqué si le type de document est .xlsx,. docx.

Problème - Point n ° B: problème lié au fait que le type de contenu correct n'est pas balisé et que le type de contenu par défaut est balisé si le type de document téléchargé est .xlsx ou .docx. Cependant, le même type de contenu, le même champ personnalisé fonctionne si le type de document est .xls ou .doc.

Appréciez vos contributions à cet égard.

Merci d'avoir pris le temps de lire mon post.

Cheers, ~ Poonam

Answer 1

Je ne sais pas pourquoi cela se produit, il pourrait être une bonne idée d'informer Microsoft de ce comportement. La différence entre .doc et .docx que vous décrivez est très, très étrange. Pourriez-vous essayer de définir le type de contenu dans un itemeventreceiver, pour forcer le champ ContentType ou ContentTypeId de l'élément à refléter le type de contenu correct explicitement.

-à-dire

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

the_part_added_by_list est le guid supplémentaire qui est ajouté lorsqu'un ctype est ajouté à une liste c'est parce que ctypes dans une liste sont essentiellement des enfants de la ctype réelle que vous avez ajouté

-à-dire 0x010100 YOURGUID 00 LIST SPECIFIC GUID,

vous pouvez obtenir cet identifiant complet en utilisant un outil comme Stramit CAMLViewer, ou progr. en bouclant à travers la collection ContentTypes du SPLIst.

(je pense serait de le faire en cas ItemUpdating/ItemUpdated pour voir s'il y a une différence dans ctype au cours de ces appels)