I'm trying to find how a field's value has changed in an ItemUpdating event receiver. The particular field's display name and internal name is Regions.
As soon as ItemUpdating is hit, the value of the Regions field is identical for the following:
properties.AfterProperties["Regions"]
properties.BeforeProperties["Regions"]
properties.ListItem["Regions"].ToString()
I would expect the latter two to contain the old value but surely AfterProperties should be set correctly.
Does anyone know how I can obtain the changed value?
Update: The event handler is attached to a MOSS 2007 publishing Pages list.
I've had a lot of trouble with event handlers on publishing pages libraries. Think it comes from their being other event handlers on there already for publishing. I had better success with updating, can you change to that or do you need the sync event to block the change ?
Are you trying this in a List or Document Library ?
It will work Only on the Doc Lib Please refer to these
MSDN and another on same subject
Related
The issue is that everytime an item is edited/changed all the users who are set up to receive updates are notified. I need the workflow to run only when a specific field is changed disregarding the others. For example if my item contains these values (Customer Name; Acc#; Contact Person; Address;) - I need the workflow to work only when the Acc# is changed and only if it is changed, no metter how many times the other fields are changed.
Thanks,
A quick way to do it is to have the workflow store the value each time the it starts, then tell it to wait until the field != the stored value. This may not work in all cases, but it could be enough for your purposes.
You should create an event handler to run on your content type or library. You can then check the before and after properties of the fields you mention. Then use the event handler to initiate the workflow if required.
I am writing a web part against a list. The first thing I do in the web part is verify that my custom event receivers are registered on the list. If they are not, I register the programmatically.
I have noticed that if I try to register an event that is already registered, I get no errors and no “Extra” events are registered.
My question is: Would it be more efficient to just register the events each time the web part loads rather than iterating through each event in the event receiver list and doing compares to see if each of my event receivers are there?
Edit
About the Property bag suggestions. After thinking a bit more about it, this will not be a feasable solution. The reason that I am "verifying" that the receivers are there is because we have 3rd party webparts that are attached to the same list. These have, in the past, actually unregistered our custom receivers. Setting a flag in the property bag will just let me know that I have verified once, but won't tell me if they get removed by another.
The code that SharePoint uses to update an event receiver collection is obfuscated, so there's no way to know for sure. I would guess that the first step is a check similar to what you are doing manually. I'm inclined to go with what's easiest until you identify that performance is an issue, in which case I would set a flag on the list's RootFolder's property bag.
I unsure if this is best approach. I have seen a code that does something similar to your requirement. What it does is that once the EventHandler are added they stored a flag in the SPWeb Property Bag. Next time you just check the Property bag for the flag if it is there dont register the eventhandler . Refer this link for more information about the property bag. Final note you might need more permission to set the property bag value to SPWeb
I'm aware of the event receivers on a list for items added etc. However, I have not found a way to fire code upon the creation of a list.
What I'm trying to do is associate a workflow with a list when the list is created (by the user through the UI).
Anyone any ideas?
thanks.
There are a couple of routes you can take...
You can write your own list definition where you have defined the workflow association - That way all lists created based on your list definition, will contain your workflow on default.
Or... depending on your workflow... write an EventReceiver your attach to all lists of the type you wish to attach your workflow to (can easily be achieved tru a feature) and have your event receiver associate the workflow when the first item is added.
or you can associate the workflow to the contenttype used in the list (your own contenttype you attach to your own list definition or a default SharePoint contenttype)
I don't know the rest of your solution, so it's defficult for me to suggest the best solution for you.
What I (almost) always do, is write my own list definition - That way I can avoid problems like this, now or in the future.
With SharePoint 2010 it is now possible to hook into the list creation event by overriding the ListAdded event in the SPListEventReceiver class.
I usually deploy an extra view page which is set to the default view. When the user creates the list he will be sent to the viewpage which contains the setup in code behind. The view page then calls a method ive created, which changes the default view, removes the setup view and change any navigation node pointing to the setup view.
There is probably no perfect answer to this question because there is no list added event receiver (if memory serves me correct).
I don't know if this is the case, but if you really just needed to register an itemadded (or updated, deleted, etc.) event to any new list, I believe you can register the those events at the site (SPWeb) level and they will fire on any new lists created.
I have a simple event handler with a ItemAdding event that changes a column value that I need in the ItemUpdated method. After uploading a word 2007 document (*.docx, *.pptx or xlsx) the value of the column is changed, but when I protect the document the value of the column disappears in the ItemUpdated method. This only happens for office 2007 documents, other files don't clear the value.
The event handler runs in a document library in MOSS 2007.
Thanks
We have the same issue. It appears that the properties from the list are added to the office 2007 doc, but only with the default values for the field on upload/creation. Once the item is edited we are experiencing that the office documents values are overriding the values set in our event handler.
We do not experience this when using an asynchronous event handler, but the asynchronous event handler has conflicts with updates on other threads with certain types of updates.
We have a support call active with Microsoft about this very issue. They acknowledge this is not
No results yet.
Try using an asychronous event handler (it runs a little bit later than the code that updates from the office document), but with caution.
UPDATE:
A workaround is setting the SPWeb.ParserEnabled to FALSE will remove the connection to the document properties which will stop the above behaviour. It prevents the list properties from being added to the office document.
When you upload an Office document into SharePoint, it tries to extract column from the document and promote them to the list.
Do, check if your doc has any attribute set. If this is the case, it can explain what you see.
Note: open advance document properties and delete all custom properties to be sure
I resolve the issue putting the SPWeb.ParserEnabled = false in the ItemUpdating method.
code:
properties.ListItem.Web.ParserEnabled = false;
Thanks all for help
Setting SPWeb.ParserEnabled = false does work, but there are effects! One very noticeable one is that it will break site and list templates. If SPWeb.ParserEnabled = false, and you save a list or site template, it's meta data is not set (Feature ID, Product Version, etc) and it will not be available in the list of templates to choose from. You might be able to get around this by resetting SPWeb.ParserEnabled=true during the itemUpdated event, but I haven't fully tested whether this will resolve all issues yet...
I am listening on a particular SPWeb using an SPWebEventReceiver that is successfully firing on the WebMoved event. When the web is moved I update a list with the new location/title.
What I would like to be able to do is listen for when the Web is renamed . Do I do this by attaching an item listener and waiting for an ItemUpdated event? If so I would appreciate a little snippet of code! Thanks!
It looks like this is a bug with the SharePoint OM. The event receiver is clearly supposed to fire when the name of a web is changed, but it does not. It only fires when the Web's URL is changed.
Steve,
As far as I can see, SPWebEventReceiver only exposes the following events on an SPWeb (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spwebeventreceiver_members.aspx)
SiteDeleted
SiteDeleting
WebDeleted
WedDeleting
WebMoved
WebMoving
ItemAdded is defined in SPItemEventReceiver which is applicable to SPListItem objects.
The Title property of an SPWeb is stored in a property bag (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.properties.aspx).
It doesn't appear like you can tap into any events when .Update() is called on the property bag, e.g. when Title is updated.
I would say that a rename of the Web name should trigger WebMoved.
Site title rename triggers no action.
Question: What changes do you want tot tap in? Because any metadata for instance could be stored in lists inside, which supports lots of events.
I don't believe it is a bug, I believe it is simply a misinterpretation of the documentation. As you have stated, the documentation indicates that the WebMoving and WebMoved events are triggered by the site's url being modified or being renamed:
from MSDN Doc: "Synchronous Before event that occurs before an existing Web site has been renamed or moved to a different parent object."
However, what gets changed in the UI is NOT the "name" of the site, but the site's title. The SPWeb object does have a "Name" property that is accessible through the Object Model, and updating that Name property and calling SPWeb.Update() does in fact trigger the WebMoved event. The trouble is that this property is not exposed through the web-based settings page for the site, only the "Title" field is exposed, and this field change does not trigger the event. While this seems a bit counter-intuitive and even misleading, if you read the documentation literally, it is behaving exactly as documented.