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...
Related
I have a SharePoint document library I am working on. It has a list of document sets. Each document set has a few fields that are marked as "Shared" so that they can be inherited by the documents inside.
When I upload a document inside a form opens and all the fields on the form are pre-filled with the shared values of the corresponding columns. But when I use create document from template, it opens the template in the corresponding Office application but the document property fields are empty and not read-only which is against the requirements of this project. I require them to be synced and filled exactly like when a document is uploaded.
There is one thing though. The user can fill any value he wants in those fields and they will still be saved a synced copy from parent in the library discarding what the user filled in, which is good, but why not show those values up in the document in the first place?
Anyone has experience in handling this please help. I have searched a lot on the internet but either my keywords are wrong or no one has had this problem before.
SharePoint version: 2010 Server
Office version: 2010 Professional
It sounds like you need a simple event reciever, which fire on itemadded. It would then go back up the tree to find the document set. Capture which properties are marked as shared. Adjust the item that is being added to force the values.
Probably 8 lines of code
We would like to block the deletion of documents in a list based on some custom functionality.
What we have tried is to implement this in the ItemDeleting event. Where we set the cancel property of SPItemEventProperties to true when we do not want the user to be able to delete a document.
What happened was that the Delete option in the dropdown menu disapeared when the user was not allowed to delete a document. In a way this works, but the event is firing before the user actually tries to delete the document.
What is giving us problems is that the user can delete a document if they connect to the document library via MS Word 2003. In that case it does not appear that the ItemDeleting event fires.
Is there a way that we can get an event to fire and rollback the deletion when the document is deleted via MS Word.
Edit
Part of the problem could be that events do not fire in explorer view. Is there a fix for this "bug"?
ItemDeleting - An event that fires before an item is deleted.
more click here
I do not have sharepoint development environment right now so I can not give the exact answer but you can check on one thing that when user performs any action on a document from MS Word 2003 ItemUpdating event is fired. You can explore ItemUpdating event to see what is going to happen with the document and then deal with it accordingly.
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
Which is the best way to display a custom form for each new document being added to a specific document library?
I want the user to have some control over some actions that adding the document will cause - specifically, tasks created for users in a Task List, which the contributing user will have to OK before committing.
Is the best way to do this via a Workflow or an event handler?
Regards
Moo
For SharePoint server 2007:
A combination of a specialised content type and an event handler will give you the most control of the process (easier to debug too). A workflow is best for "easy" actions and is harder to make complex actions happen.
A workflow allows for more flexibility in assigning the workflow to different libraries by site admins.
Roll your content type and event handler into a feature that can be deployed. Assigning the content type to a list will allow you to take any data created by the standard form (remember you can create custom fields for really complex/custom data entry) and take any action required, including creating tasks based on the item.
Thanks for the answer, thats the route I was investigating but unfortunately I haven't found a way to make it work for Document Libraries - only Lists.
The problem I have come across is that aving a SPUtility.Redirect in the ItemAdded, ItemAdding, ItemCheckingIn or ItemCheckedIn event on the document library doesn't do anything at all, because there is no page related to the events - its all backend code being fired that is not linked to a web context, because its not the webpage doing the heavy lifting at that point but the Office integration.
All of the examples I have come across seem to rely on the fact that the EditForm.aspx or NewForm.aspx page is being displayed at the time the event is fired, which of course is not the case here.
This also leads to the problem that I cannot extend the EditForm.aspx or the CheckIn.aspx page to do what I want either, because Office 2007 circumvents both of these.
So, the only option left open to me at the moment is doing it through a workflow :/
Any further tips would be fantastic.
I may not understand your question, but is this close to what you're trying to do?
http://msdn.microsoft.com/en-us/library/ms550037.aspx
If not, in what way does this come up short?
A new "Content Type" with its New Form url set to the appropriate value should do the trick.
Unfortunately you may not be able to achieve what you are trying to with an Event Handler or a Workflow. You would ideally want the form to show up as soon as the user adds a new item to the library and a custom content type will do the trick.
Create a new Content Type. (Derive it from the existing Content Type)
Remove the default content type from the doc library.
Using the Object Model to set the New Form url to an aspx page or an Infopath form you've created.
Kind regards,
I am using VSTO 3.0 and the ribbon designer gives me a ribbon that is apparently shared across documents.
So if I have Document specific state( number of XML marked up tags say) that needs to show up in the ribbon( or a toggle button ) then all documents seem to share the ribbon instance
How can I fix this
TIA
You can use Application.DocumentChange event or Application.WindowActivate event.
The first is fired then you change the current active document, but in the arguments there's no information about that document, so it's difficult to work with because you'll have to figure that out.
The latter is similar and it's fired every time you change of window but in this case it passes the current active document as an argument, so it's easier to change the ribbon if you need to check the value of any document property. That worked for me.
Hook into an appropriate event (such as when the active document is changed) within the document model, and in that event invalidate the appropriate ribbon button (you'll need the id of the element from the original Ribbon xml you load).
Then, when the refresh state callback for that button occurs, you can update the caption/image/enabled as required.