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;
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!