Wednesday, September 27, 2006

Synchronous Add List event (ItemAdding) will not give access to item properties


I have had a chance to look into this again now, and found that indeed it is possible to access and change properties in ItemAdding, if you are doing it through the "AfterProperties" hash table of the event, and not through the list item.
Some things to note:
During ItemAdding, there is no SPListItem object to refer to. It is null in the event properties, because to get an SPListItem a record for the item should be in the database, and during ItemAdding nothing has been written to the database yet.
After ItemAdding, the item is added to the database. When it is added, the values from the AfterProperties are applied to it. If you try to add a property to that hashtable that doesnt exist in the list definition, the user will get an error that the field isn't installed correctly. You may encounter this if you don't use the internal name of the field when you set the AfterProperties.
The moral of the story - Use the AfterProperties in ItemAdding, and when you use it to get or set a field, make sure you use the field's internal name.
That said, my argument with Sahil (see below in the original post) remains - you cannot use the SPListItem, because one cannot exist. His sample code modifies the item that was added before the current item, and not the current one.

Here is a sample code that modifies one of the fields in the ItemAdding event. In this example we have a links list, with a custom column called "Tool Tip" (internal name is "Tool_0x0020_Tip") and we want to set it automatically to the title of the link the user picked:

public override void ItemAdding(SPItemEventProperties properties)


            string toolTipFieldInternalName = "";

            using (SPWeb web = properties.OpenWeb())


                toolTipFieldInternalName = web.Lists[properties.ListId].Fields[TOOL_TIP_FIELD_NAME].InternalName;




            string urlVal = properties.AfterProperties["URL"].ToString();

            SPFieldUrlValue val = new SPFieldUrlValue(urlVal);

            string desc = val.Description;

            properties.AfterProperties[toolTipFieldInternalName] = desc;


Original post: (was posted during Beta2) Ok - here is an update to my "Bad news - synchronous list events bug (or missing feature)" post from August:

I reported this as a bug to Microsoft, and got a response that they "cant repro this on a newer build - please check on TR".
So I waited for TR, and checked again - no change! The properties of the new list item are simply not accessible.
I reported this to MS, and this time gave a full code sample so that they will be able to repro exactly what I was trying to do.
The answer came back that this is by design!

Microsoft has no plans of giving us developers access to list item properties in the itemadding event. All you will know is that an item is being added. You will notice that the SDK was also updated to show a sample code that checks the number of items in the list and shows a user an error if there are 150 items in the list. But checking the new item's properties can only be done in the "itemadded" event.

By the way, this means that Sahil's example does have the bug I pointed out - during itemadding, the item is not yet added to the list and is not available through list.Items[list.Items.Count-1].

People- I think this is big enough that we should gang up on Microsoft and clamor for them to give us the ability to check properties of list items. Write comments here if you agree and we will build us a petition!


Anonymous said...

The same problem applies to using itemupdating. You can not get access to item properties. Very annoying. Asked Microsoft. They gave the same reply (By Design). I find this unacceptable.

Anonymous said...

I had the same problem but with the itemupdating event. No way to see the value of the new list properties. Were you able to find any resolution to this? Microsoft got back to me with their "As Designed" reply...

Thoughts? Ideas?

Suresh said...

I also agree with you. I am using Item ading event to insert data to some of my list item's field which is hidden to user. but the data is not inserted to those fields. Furthermore , i have a workflow on that list item.I want to the workflow to be executed after my code in Item Added event is executed. But it is executed before this event. How can i control the workflow.

Sheetal Jain said...

Thanks god I stumbled upon your blog.. I was going insane... Look like whoever design this event certainly didn't have clue on how people are going to use it.. What is the whole point of giving this placeholder if we can't the data????

It is true... MS gets everything right in 3rd attempt... So wait till Office14

Sheetal Jain said...

I agreee.... This is useless without data....

A. Quneibi said...

I also agree with you. I would like to use Item adding-event to fill data to some of Item-fields which are hidden to user, but this is not possible.
I have to Insert the Item, and then fill the Data to it. I do not know if this Event makes any sense!!!!

Anonymous said...

I'm sure we need access to properties in ItemAdding, if not, why we want that event? just to limit the number of items in the list?... I don't think so

Keith said...

Iterating through the properties worked for me, e.g.:

foreach (DictionaryEntry de in properties.AfterProperties) {
string myValue = de.Value;
string myKey = de.Key

Anonymous said...

Dear Readers,
Thats for your posts.
I have been trying for this since 2 months at last i found this article and came to know that was issue, i find this so stupid why microsft will do allways like this, without exposing the properties in ITemadding and itemupdating what is the point of exposing that event handlers....
any way i was very much needed this can any one has any idea please write a email to me...
i have a calendar control and using this control i will book meetings, my problem is i don't the users to book duplicate time slots ..

Anonymous said...

Interestingly, ItemAdding() and ItemAdded() do not work/fire for Lists at sitecollection level ("User Information List") in WSS 3.0.

A bug in WSS (or perhaps there is a reason why it wouldnt work..)


rsriram22 at hotmail dought com