I'm trying to do some changes to the properties of the documents that users edit in a Sharepoint 2010 Document Library progammatically using an Event Handler. At the moment, I'm trying with the event ItemCheckedIn. The problem comes when I execute the following instruction:
item.File.Update();
It gives me an exception saying that the document is locked by user XXX.
Am I updating the properties in the wrong event? How can I avoid this exception?
Thank you in advance.
Try using
item.SystemUpdate()
instead
Microsoft Office Word is issuing a lock request on documents by default and it is different than 'Checked Out' state.
'Lock' is release only after document is closed by Word. While 'Check Out' can be performed via Word or web interface and it would remain such until explicitly requested to 'Check In'.
As previous comment suggest, the best remedy is to to use in your code:
item.SystemUpdate(false) as that would not obey to 'Lock' state and save any changes done via Event handler code.
Related
I frequently receive ok-only prompts while automating add-ins in Excel, stating that Microsoft Excel is waiting for another application to complete an OLE action Error. How to use Interop.dll to show a custom message and handle this error programmatically. Before receiving the promptenter link description here
While You possibly can catch these exceptions depending on your automation framework and do something with it - these type of errors typically comes from not closing the files properly when changing from one to another.
Make sure you dispose all that can be disposed and close all which can be closed in reverse order obviously and it should go away.
If You need more details do post your code for opening and closing looks like a bug there which will make it not coming up.
You do not technically have to use interop, could you consider using a more modern package for interacting with excel?
If you are using google drive / file stream then this may be the problem. Turn off "Real Time Presence in Microsoft Office" then the messages go away.
Experienced .NET developer here (but only client object experience in SharePoint). Here's my scenario:
In SharePoint 2013 a user checks in an existing/new file after making changes
File check code (c# pref) is run against the file being checked in
If file passes checks continue check in
If file fails, discard check in, inform the user that the check in has failed & provide the reasons why it failed (reasons supplied by file check code).
I already have the file checks implemented as a c# class lib (used in a couple of other apps). I would like to be able to limit this to a specific folder (and all child folders within) and file type (identified by file extension).
What's the best practices method of implementing this? My guess is to tie into existing SP events to determine check in and insert my file check class into that execution path. In a perfect world I'd find a tutorial demonstrating this. :)
Thank you in advance for your time.
Regards,
Falconeer
what you want is to develop a SharePoint farm solution which uses the event receivers. There are specific event receivers which will fire when someone checks in a document. Then you should do your logic there.
http://beginnersbook.com/2013/02/event-receivers-in-sharepoint/
Watch out for the event receivers - checkingin - checkedin. There is a difference between the two. The one is synchronous, the other asynchronous. I would put your logic in the -ing event receiver as this allows you to cancel the checkin.
You might have to play with before and afterproperties to do the appropriate check on folder, file, etc...
http://www.sharepointalex.co.uk/index.php/2010/06/beforepropertiesafterproperties-in-event-receivers-i-always-forget-this/
This should be the way to go!
I was wondering if anybody had any experience with dealing with managed code add-ins specifically for Visio in a .NET project. I am messing around with one and am trying to remove hyperlinks from a Shape object. Deleting them works fine and if the user saves then all works well. The problem arises when the user does not save and is prompted by Visio, before close, that there are unsaved changes and wants to know what the user wants to do. If the user selects "Don't save" and just tries to exit, the Visio application crashes with an unhandled Win32 exception that I have traced back to an Exception code: 0xc0000005 in the Windows Event Viewer. This turns out to be an "Access Violation Error". I have found the issue to be a line of code that calls the Delete method on the Hyperlinks collection of a shape (Example below). Anybody know what is going on here? Is this a MS bug that I just can't find on the Google? Hope I have enough information for you guys here. Did not think I needed to post a bunch of code since I have found only this line of code produces the exception when Visio tries to exit after a do not save. I have found this to produce the exact error with versions 12 and 14 of the Microsoft.Office.Interop.Visio.dll.
internal static Nullable<Boolean> DeleteFirstHyperlink(Shape shape) {
if(true){ //a condition to pass
shape.Hyperlinks.get_ItemU(0).Delete();
return true;
}
else{
return false;
}
}
I think you might be deleting hyperlinks from a "before shape deleted" event handler? I this case, you should not do that. Instead, you can remember what to delete and delete it afterwards in "no events pending" / "shape deleted" event handler.. Or it may be some similar case.
Check here: https://msdn.microsoft.com/en-us/library/office/ff767512.aspx
After Visio has fired the MustFlushScopeBeginning event, client programs should not call Visio methods that have side effects until the MustFlushScopeEnded event is received. A client can perform arbitrary queries of Visio objects when Visio is between the MustFlushScopeBeginning event and MustFlushScopeEnded event, but operations that cause side effects may fail.
If this is not the case, then probably one would need a complete example illustrating the problem (full source code illustrating the problem) to figure out what is going on.
I mean, normally you can delete hyperlinks without any issues.
I am creating an automation solution for Word (2007). Sometimes I have to kill the Word process. Next time word is launched a tab/window appears suggesting to recover an unsaved document. I would like to either disable this or have my application close this window.
I have no idea where the entry point to this tab/window is.
EDIT: I've found out that word calls this "Feature" Repair, not Recover. Still no idea how to avoid/bypass/disable it.
Suggestions?
This can be solved by deleting the Resiliency key in the Registry before starting Word again. This is described here:
Every other time that you open a document in Word, the document opens in recovery mode or you receive an error message
You can safely delete the entire Resilience key for local machine and the current user. Note that there are various places where the key is stored:
HKEY_CURRENT_USER\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\\Word\Resiliency
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Office\\Word\Resiliency
I assume you have access to the word:
http://www.ehow.com/how_6012331_disable-document-recovery-word.html
[edit]
Seems this doesn't work, you could try
Options.SaveInterval = 0
(source: http://www.tech-archive.net/Archive/Word/microsoft.public.word.customization.menustoolbars/2004-07/0195.html)
but I assume this gives the same effect as what I said first.
[/edit]
Its not possible atm. Maybe on next SP...
I want to get an event Before a file is being deleted?
How can I do it?
As per my answer to this question: How could I prevent a folder from being created using a windows service?
There's no support within the System.IO.FileSystemWatcher, or anything else within the .net Framework (as far as I'm aware) for receiving an event prior to a file being deleted, i.e. at the point the deletion request hits the file system, but prior to it being actioned (I'm assuming here that you want to be able to selectively cancel requests to delete files).
What you'll need to do, if you want to go down this route, is write a File System Filter Driver, which you'll have to write in unmanaged code as far as I'm aware.