I guess I could write an association form - but given that this workflow will only be used on one list, and that the settings shouldn’t change very often, this would be like using an anti-aircraft gun to kill a mosquito.

It is really frustrating to have simple tasks, no documentation, and no answers. I mean, come on guys, all I want to know is the right way to install a config data, and access it.

The ECM Sample Starter Kit has an example that uses an Infopath Modification form to do just that. Looking at the code for it, I can see how it has an ‘EnableWorkflowModification’ step to, well, enable a modification form, and I looked this up on the MSDN site.

The MSDN site pages I looked at here and here discuss the scope of the enabled form. However, this seems to be related to the step it is contained within a sequential workflow. This, presumably, doesn’t apply in a state machine workflow? Or maybe it applies to the whole state (i.e. the state is the scope)- which raises questions as a state might be reached by many routes, without enabling the modification.

Event receivers, well, receive events that happen on an item, and process them. I listed the ones on my workflow task list with the following code:

for (int j = 0; j < myList.EventReceivers.Count; j++)
{
SPEventReceiverDefinition d = myList.EventReceivers[j];
Log (d.Assembly + ” - ” + d.Class + ” - ” + d.Data + ” - ” + d.Filter + ” - ” + d.Name + ” - ” + d.Type.ToString());
}

This gave the the results:

31/08/2006 11:13:57 - Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c - Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver - - - - ItemAdding

31/08/2006 11:13:57 - Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c - Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver - - - - ItemUpdating

31/08/2006 11:13:57 - Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c - Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver - - - - ItemDeleting

31/08/2006 11:13:57 - - - - - - 32767

It turns out that there is an easier way of list the event receivers, but dumping to a log file works. Interestingly, he also had the same 32767 result, which is weird. It’s (2^15)-1, so presumably the highest value that can be represented by a 16bit signed integer - but what is it doing in my log?

Anyway, I reckon that the ItemUpdating event receiver is killing my update - but don’t effing know why.

Incidentally, this is a good article demonstrating event receivers. Shame about the bugs they’re finding, though.

private void onTaskChanged1_Invoked(object sender, ExternalDataEventArgs e)
{
SPWeb mySite = new SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);
SPList myList = mySite.Lists[workflowProperties.TaskListId];
SPListItem myTask = myList.GetItemById(TaskBeforeProperties.TaskItemId);
SPUser myUser = mySite.AllUsers[e.Identity];
myTask["Assigned To"] = myUser;
myTask.Update();
}


Everything seems okay, but when I call myTask.Update(), I get the exception “An event receiver has cancelled the request.” And I’m damned if I know why.

2) Extract the public key:
Sn.exe -p PublicPrivateKeyPair.snk PublicOnly.snk

3) Calculate the token. Note that the ‘-t’ parameter MUST be lower case (’-T’ does something different)
Sn.exe -t 'PublicOnly.snk'
And there you have the public key token

Right, so, I started with some code to get a SharePoint column, update the column, and save the changes.


SPWeb myWeb = new
SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);

SPListItem myItem =
myWeb.Lists[workflowProperties.ListId].
GetItemById(workflowProperties.ItemId);

myItem.Properties["Column Name"] = “Column Value”;
myItem.Update();

This worked a treat - but only for columns defined normally. Columns being read from the form lost their values as soon as the update() function was run.

And that was the problem - the values were being read from the form data, the XML. I had hoped that SharePoint would be clever enough to write back into the XML - it isn’t. Instead, it appears you have to do this by hand…

First, get the SharePoint Listitem


SPWeb myWeb = new SPSite(workflowProperties.SiteId).
OpenWeb(workflowProperties.WebId);
SPListItem myItem = myWeb.Lists[workflowProperties.ListId].
GetItemById(workflowProperties.ItemId);


Then get the File for that ListItem - i.e. the XML data


SPFile myFile = myItem.File;
MemoryStream myInStream = new MemoryStream(myFile.OpenBinary());
XmlDocument myDoc = new XmlDocument();
myDoc.Load(myInStream);


Then make your changes to the XML in here - below is what I did, as an example


XmlNode myRoot = myDoc.DocumentElement;
XmlNamespaceManager xmlNSManager = new
XmlNamespaceManager(myDoc.NameTable );
xmlNSManager.AddNamespace("myNameSpace",
"http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-06-08T14:13:41");
XmlNode myColumnToAlter = myRoot.

SelectSingleNode("/myNameSpace:WFTaskForm/myNameSpace:myColumn", xmlNSManager);
myColumnToAlter.InnerText = "This has been changed";


When you’ve finished changing your XML data, save the XmlDocument object back into SharePoint as a file.


MemoryStream myOutStream = new MemoryStream();
myDoc.Save(myOutStream);
myFile.SaveBinary( myOutStream.ToArray());


Took me a ridiculous amount of time to figure all that out. It’s a good job that SharePoint makes it so easy…

Actually, I can see why they did it this way - but throwing an exception when I tried to write to the columns being read from the form would be useful. And maybe some instructions somewhere about how to do this. Still, maybe this will prove useful to someone…