forge

More SharePoint Workflow Quirks – Tasks, Debugging, Content Types and History Pages

In my continuing quest to conquer SharePoint and Workflow I’ve run into a few interesting things that may be helpful to you.  They appear below…

Help Your SharePoint User
  • The taskid in the createTask, onTaskChanged, etc., activities (or the property they are bound to) is not the uniqueid for the task.  As a result you can’t use workflowProperties.TaskList.GetItemByUniqueId(tasked) to get the task created by the workflow – which you’ll want to do since the properties in the workflow are not necessarily synchronized with the values in the task.  The way to do this is to use the SPQuery object to query the taskList with the tasked matching up to the GUID field in the task list.
  • The workflow history page reports workflow time relative to PST time – for some reason it ignores both the server and client time timezones.  This isn’t a big deal unless you’re trying to figure out why someone was starting workflows at three in the morning.
  • Delete task requires that you set the taskID with the MethodInvoking event handler (at least it did for me.)  I’m not sure why this would be the case, but it resolved an issue I was having with it trying to delete a task with an ID of all zeros.
  • Attaching the Visual Studio debugger to the W3WP.EXE process causes the W3WP.EXE process to start consuming 100% of the available processor time.  I’m not sure why but I’ve seen it happen repeatedly on my development server.  My recommendation is to attach the debugger at the last possible moment and disconnect it as soon as you done.
  • Content Types don’t use Guids for their IDs, they’re passed around as hex strings – but not GUIDs.
  • When debugging workflows you don’t get first chance exceptions even if you’ve asked for them.
2 replies

Comments are closed.