More on Updating SharePoint Workflow Tasks

So, I’ve continued investigating my problems updating a SharePoint Workflow Task. I decided to learn about event receivers, as this is what the message was about.

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.

More on Updating SharePoint Workflow Tasks

Updating SharePoint 'Workflow Tasks'

Problems doing the simplest things. I want to update a task created by the CreateTask activity, when the activity is changed. I have the following function, which is run when the Task list item is edited…

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.

Updating SharePoint 'Workflow Tasks'

Error in SharePoint Logs – Load Workflow Assembly: System.IO.FileNotFoundException

This one puzzled – the file name in the Workflow.xml ‘CodeBesideAssembly’ was correct, and I thought the PublicKeyToken was okay too. Turned out that the ‘version’ was wrong – it seems to start at 3.0.0.0, but my assembly was only 1.0.0.0. Dunno why that was.

Error in SharePoint Logs – Load Workflow Assembly: System.IO.FileNotFoundException

Getting the Public Key Token without copying things into the GAC

1) Create your Key pair, as per normal. Typically, this can be done as:
Sn.exe -k PublicPrivateKeyPair.snk
This will create a file containing both keys.

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

Getting the Public Key Token without copying things into the GAC

More about frozen panes…

So, I’ve been working with ‘Frozen’ panes in tables in HTML. The problem is, some of these tables are, well, a little big. Like maybe 100 cells square. I found that the technique mentioned earlier in my blog didn’t work very well, as the scrolling on the DIV tag became slow and jerky.

This makes sense really – each cell is having it’s CSS rerun each time. Then it struck me – the styles were defined as:

td.frozen {
padding: 3px;
position:relative;
top: expression(document.getElementById('pane').scrollTop-2); /*IE5+ only*/
z-index: 5;
}

This mean that ‘getElementById’ was being run repeatedly. However, the style’s JavaScript was being run before ‘onload’. I just couldn’t run the ‘getElementById’ to populate a global variable after the element had been created, but before the style expressions were run. Instead, in a moment of clarity, I changed the style to:

td.frozen {
padding: 3px;
position:relative;
top: expression(getPane().scrollTop-2); /*IE5+ only*/
z-index: 5;
}

And added a script:

var pane;

function getPane() {
if( pane == null ) {
pane = document.getElementById(“pane”);
}
return pane;
}

Thus, we only run getElementByID once – the first time a CSS style’s javascript expression is run. This worked – the DIV tag now scrolls much more quickly, certainly not so as users will notice any lag.

More about frozen panes…

"malformed header from script"

So, in testing simplyXiangqi, I found I was getting error pages when I tried certain actions. The actions seemed to happen okay, but I got the standard Rail ‘Application Error’.

Looking in the logs, I was getting an error ‘malformed header from script’. ‘Curious’, I thought. The full error was of the form:
malformed header from script. Bad header=isRed = 1:
/home/simplyxi/public_html/dispatch.cgi

It seemed to me that part of my code was appearing as a header when the page was returned.

Eventually, I figured it out. My code still had ‘puts()’ calls in it. I’d added these for debugging during development on WebBrick. In WebBrick, the strings output by ‘puts()’ were written to the command window WebBrick was running under. On my Apache installation, though, this was output as a header. Consequently, I got errors.

I removed the ‘puts’ calls, and it all worked fine.

Comments from my old blog:

Thanks, buddy. Saved my sorry ass. 🙂

By Magnus Bergmark at 18:07:07 Saturday 29th September 2007

"malformed header from script"

Dispatch.cgi and End of File Characters

So, I was setting up my Chinese Chess site (domain name might not have propagated yet), and I had some problems. I kept getting the error ‘Application error: Rails application failed to start properly’. Looking in the logs the error was “Premature end of script headers: dispatch.cgi”. Tracked this down to the Dispatch.cgi file through Google, where other folks seem to have had problems with the EOF character.

I couldn’t figure out how to delete these characters – why is it that ‘vi’ is so popular? – so what I did in the end was create a new rails app and copy the cgi files across into my app. The files, although they appeared to have the same text, had very different file sizes.

Anyway, that seemed to do the trick.

Dispatch.cgi and End of File Characters