views:

322

answers:

1

I wound up modifying the source from a publically posted POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, which is a custom field definition for cascading drop downs. The modifications were to allow parent-child list boxes where a user can multiselect for filtering and selecting the values to be written back to a SharePoint list. I got the parent-child cascading behavior working, but the save operation only takes the default Content Type value.

I changed the base type for the custom field control from "SPFieldText" to "SPFieldMultiChoice", along with changing the FLD_TYPES field definition values from: "Text" to "MultiChoice"

Steps Explained: 1. The custom field is created which is derived from ‘SPFieldMultiChoice’ class. The custom field allows multiple values to be selected. 2. The Field created using above custom field is added to custom content type created from GUI derived from ‘Document’ Content type. 3. The custom content type is added to the document library. 4. The document is uploaded and custom content type is selected and tagged to document. A. The correct content type gets tagged with correct metadata if type of document is .xls,.doc,.txt etc B. The default content type i.e. ‘Document Content Type’ gets tagged if type of document is .xlsx, .docx.

Issue Summary – Point#B: is an issue as correct content type is not tagged and default content type gets tagged if type of uploaded document is .xlsx or .docx. However same content type , same custom field works if type of document is .xls or .doc.

Appreciate your inputs in this regard.

Thanks for taking the time to read through my post.

Cheers, ~Poonam

A: 

Not sure why this is happening, it might be a good idea to notify Microsoft of this behavior. The difference between .doc and .docx you describe is very, very strange. Could you try setting the content type in an itemeventreceiver, to force the ContentType or ContentTypeId field of the item to reflect the correct content type explicitly.

i.e.

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

the_part_added_by_list is the extra guid that is added when a ctype is added to a list this is because ctypes in a list are basically children of the actual ctype you added

i.e. 0x010100 YOURGUID 00 LIST SPECIFIC GUID,

you can get this full id using a tool like Stramit CAMLViewer, or progr. by looping through the SPLIst's ContentTypes collection.

(my guess would be to do this in the ItemUpdating / ItemUpdated event to see if there is a difference in ctype during those calls)

Colin
I have checked this with Microsoft by opening a premier ticket. I got a response which is listed below: I have been able to reproduce the issue in-house with your custom Lookup Field as well as , outside of it – that is , with a basic Field of type MultiChoice when it is added to a document Libraryas part of a content type.At this moment, it looks more like a bug, though I cannot confirm it now. I am researching more on it, and will keep you posted of more information I find regarding this issue.
Poonam