Sharepoint Gotchas
Tips and gotchas that could come up in sharepoint development
Searching for a way to check if a workflow is running on a list item (useful, for example, in an item event handler), I found some code like this: public static bool IsWorkflowRunning(SPListItem listItem, Guid workflowId) { foreach (SPWorkflow workflow in listItem.Workflows) { if (workflow.ParentAssociation... == workflowId && workflow.InternalState == SPWorkflowState.Running) { return true; } } return false; } What this code does is iterate the workflows list for the item (point...
If you're developing workflows for SharePoint 2007, you are probably familiar with the Item property of the SPWorkflowActivationProperties class. Usually your workflow gets an instance of SPWorkflowActivationProperties when the OnWorkflowActivated activity executes, which is bound to a public field on the workflow class so you can hang on to it for the lifetime of the workflow. Perhaps one of the more useful properties of this class is Item, which returns an instance of SPListItem, representing the...
The following gotcha was a pretty nasty one for me (I'd say about 2 hours of lost time worth). Supposing you have some content types deployed at the site collection level and you want to add them to a document library of a sub-site (web) plus configure them a little bit, like so: foreach (string contentTypeName in ToAttachToListContentTypeNa... { // Get site collection content type SPContentType siteContentType = web.AvailableContentTypes[c... // Add to library and configure SPContentType...
To paraphrase a heavyweight blogger, this is the first post in (probably) a infinite number of posts about Sharepoint Gotchas. Today's gotcha: why doesn't my custom content type have any columns? It took me quite some time (including a little foaming-at-the-mouth time) to figure this out. Suppose you declare a custom content type in CAML that you'd like to just inherit all its columns from its base content type, without defining any of its own, like so: <ContentType ID="0x010100D4C041607B6A400...
Due to much frustration and lost time, I'll try to summarize in this post the "naming" conventions to be used when defining and/or referencing IDs (some of which are, in fact, GUIDs, and others contain GUIDs) in Sharepoint 2007. If you're thinking "what the heck?! aren't GUIDs always the same format?!" you're half-right: they should be, but not in sharepoint. So if you're a newbie to sharepoint 2007 (or wss 3.0) like me, the following tips regarding how element id's should be written might save you...