In my former post I wrote about the approach to use custom field types as an alternative way for list item event handling in SharePoint. In the current post I would like to show you how to inject code into the edit item or new item forms using a custom field that intercepts the default item save event.
You can put the event handling in a custom field that has some other role on the user interface, or it can be a custom field without its own UI that serves only the special role of event handling. I will show you an example for the latter one in a later post.
You might ask why is it useful to be able to do that. Let’s see some examples for the usage.
Do actions before saving the item, like:
· Cross-field or even cross-list validation of the item, for example, the start date of the event must be less than the end date, or the value of the Affected tasks field for an item must be less than the count of the task items in another list.
· Extra permission checks, for example, based on the item fields, like only the creator of the item can modify the status.
· Add validation errors to the affected fields and cancel the save, if the above validations fail.
· Update field values on the fly for the same item or even an item in another list, like call a web service using the login name of the modifier and store the results in one of the fields.
Do actions after saving the item, like:
· Notify back-end systems about the change, for example, call a web service, update / insert a record in an SQL server table or create a new SharePoint list / site based on the field values.
· Redirect the user to another page.
· Set permissions on the item, for example, set write permissions using elevated privileges for the users or groups that were specified in a Person or Group field. This may be useful since it enables users with edit permissions to set item security.
There are two similar ways to intercept the base item save process, both of them is provided by the BaseFieldControl class, so you should put the code in the field control class of the custom field.
First approach is to override the UpdateFieldValueInItem method:
- public override void UpdateFieldValueInItem()
- {
- Page.Validate();
- if (Page.IsValid)
- {
- // do actions before save
- // do the save if required
- base.UpdateFieldValueInItem();
- // do actions after save
- }
- else
- {
- // do actions instead of save
- }
- }
- protected override void OnInit(EventArgs e)
- {
- base.OnInit(e);
- // add save handler only in New and Edit modes
- if ((SPContext.Current.FormContext.FormMode == SPControlMode.New) || (SPContext.Current.FormContext.FormMode == SPControlMode.Edit))
- SPContext.Current.FormContext.OnSaveHandler += new EventHandler(MyHandler);
- }
- protected void MyHandler(object sender, EventArgs e)
- {
- Page.Validate();
- if (Page.IsValid)
- {
- // do actions before save
- // do the save if required
- SPContext.Current.ListItem.Update();
- // or you can save the item using this line of code either
- //SaveButton.SaveItem();
- // do actions after save
- }
- else
- {
- // do actions instead of save
- }
- }
[…] How to override the default item save event using custom fields […]
Pingback by Cross field, cross item, cross list or even more complicated validations on SharePoint forms « Second Life of a Hungarian SharePoint Geek — January 4, 2010 @ 03:00
[…] How to override the default item save event using custom fields […]
Pingback by Creating real multi column fields for SharePoint « Second Life of a Hungarian SharePoint Geek — January 9, 2010 @ 01:36
thx for this post!
Comment by stefan walter — November 16, 2010 @ 21:10
Thanks for this. It helped me quite a bit.
I started off with Event Receivers, but soon realized that I would have to pull off a hack to get it to work with windows that were shown in a lightbox control, plus it would potentially be high maintenance and I didn’t like that.
So the next logical step was “code injection” into New / Edit windows, and this made that quite easy once this code was encapsulated in a webpart.
Comment by stevocodes — August 24, 2012 @ 07:16
nice article, It works fine in sp2010, but i am going to convert my application to sp2013, in that case oninit method is not called. how to access this method in 2013?
Comment by kiran — December 30, 2013 @ 12:54
[…] thanks to Peter Holpar for his blog post on “How to Override the Default Item Save Event Using Custom Fields.” Gave me the information I needed to create a handy custom […]
Pingback by SharePoint Custom Field OnSaveHandler and Duplicate Values | SharePoint Sawyer — June 9, 2014 @ 18:30
Thanks, Peter! A few comments on duplicate value handling on my blog post (http://wp.me/p21UoE-5H).
Comment by Paul Ewert — June 9, 2014 @ 19:31