This project is read-only.

Next Version

Nov 4, 2008 at 7:21 PM


Is this great project alive?

Any idea when the next version will be available?



Nov 4, 2008 at 8:18 PM
Edited Nov 4, 2008 at 8:19 PM
The project is definitely alive.  The delay is primarily due to the fact that both developers just had children only a month or two apart so we're pretty busy and our free time is limited.

We've very close to a release, the features are all complete and we're testing the code and the installer.  Barring any unforseen major bugs, I'd guess that you'll see a build in the next few weeks and more discussion on where the next version will go.  If you want to provide any feedback on our planned future directly, vote for the open feature items in the issue tracker.  That will help us decide what's next.


Nov 6, 2008 at 8:17 PM
The current version works though, as I can testify!  :D
Nov 6, 2008 at 9:42 PM

I'd like to hear a little bit about how you're using the tools.  Could you give us an idea about which parts you find most useful and which parts you don't like?
Nov 7, 2008 at 3:26 AM
Congratulations for all the new borns.

Yes, it is working and very well. I was considering waiting for the next release, hoping that it will ease the creations of the visual elements (visual design).That might be too late for my upcoming project.

Thanks for the clarification.

Dec 1, 2008 at 3:17 PM
First, I'll explain what I'm doing and How I came to adopt your system:

I'm using InfoPath Forms Services as a source of content. I was also using it as the workflow bits too, but the task forms are too limited.  I couldn't write vanilla C# code that took advantage of the HttpContext, and I also couldn't use the Sharepoint:PeopleEditor control (Which doesn't have an activeX dependency for it's most basic operation -- though it does degrade if you aren't using IE.)   The problem with the Forms workflow system wasn't that it was hard to implement, but that it meant that all my users had to have the office 2007 stuff installed anyway.

Basically we have a request system in which people submit infopath form templates using browser forms.  I have a workflow that operates generically on all of the forms, no matter what the content, and treats them all equally.  It interacts with a web service I wrote over top of our HR system which determines an Org Chart driven approval chain.   Having a workflow triggered automatically wouldn't be a big deal, normally, but we have the requirement of letting users submit request forms on behalf of someone else. As a result, I have to ask them 'for whom is this request?'   I also have to let them pick the target from a list of valid users.  Originally it was a big drop down list. That was awful. Then I used the activex people picker, and of course that didn't work on systems without office 2007/ie/activex enabled. 

Then I found your system, I made the custom task form using the task control template.   I was able to use the normal sharepoint people editor control, which is great even in firefox.  I convereted the whole thing including the configuration and the two types of task forms (Select who this is for Form, and the Approve or Reject Form) to your system.

So far I only have one glitch though.  In my test system it works all exactly as expected. (MOSS 2007/sp1)   But in the production environment, where I'm currently running some live tests, it always forces the Task list to some Guid name for a list instead of the List I actually pick for the thing to use as a Task list.  I can't debug it on the production system, and to my knowledge there aren't too many things that differ between it and the test host that would intuitively affect this.  So I'm not sure.  If I let it use the Guid named list, everything works, but it messes up my wiring to some controls that allow people to see what tasks they have waiting for them when they sign in.  If I could change them all over at one time, I could just wire it to the new one, but in order for me to consider my test a success I have to get it working with just one or two content types first.  There are about 50 of them that have this workflow process behind it, so it's a big investment.
Dec 1, 2008 at 4:41 PM

Are you creating the Tasks list before you create the workflow association or are you creating it by typing in a new tasks list in the association form.  If you're creating it in the workflow association, this could indicate a bug in our workflow association code.
Dec 1, 2008 at 4:44 PM
I've tried it both ways actually.  I've also noticed that when I create an association on a site collection level content-type there are no dropdown lists to choose from existing task lists, it's just free form text.  When I go to make an association to any of the inherited types, ie at the library instance level, or to the library itself, the dropdown list of all the existing task lists shows up. 

In either case I get the same results. I pick the list from the dropdown, tasks still go into the Guid named task list.
Dec 1, 2008 at 4:46 PM
Actually I take it back, partially. When I make the association to the library itself instead of a content-type, it works as advertised in both the test and the production host.  The bug is in the association to content-types.

Dec 1, 2008 at 6:32 PM

I've logged a bug and we'll get it resolved in the next release which should be coming soon.
Dec 1, 2008 at 8:43 PM
Thanks, I should have done that myself. I'm a little slow on the draw today.
Dec 11, 2008 at 3:34 PM

So I've been digging around, and I see there is a method called EnsureList which calls EnsureNamedList, which tries to grab Web.Lists[TaskListID] If it can't it creates it with the NAME TaskListID. The variable TaskListID comes from the QueryString["TaskList"] but it doesn't contain the Name of the list, it contains the Guid.  So, a list with the name of the intended list's Guid is created, even though the list has a different Guid itself as its Identifier.  I'm not able to tell how the value for TaskList in the query string gets set.  Hope that helps.

Dec 11, 2008 at 7:42 PM
OK! I found the problem! I'm not 100% sure of how to fix it, because I don't know where all your framework weaves itself together but I found why it's doing what it's doing.

(I'm also not sure why the text of my last comment was tiny and gray, I didn't do anything to get it that way. hah.)

So I figured out after much grokking of your source code that you're assuming that the TaskList post variable is going to contain the NAME of the list, not the Guid. 

In the source code of AddWorkfl.aspx, where TaskList post variable is set, I found that it actually varies! how about that?  So in the first case below it's a raw text box called TaskList, and the value will of course be the name you type into it. In the second case,  In the second case it's a drop down, with the Text being the display name, and the value being the Guid. The Guid is what's passed back and thus, a list with the NAME of the Guid of the intended target list will be created by the EnsureNamedList method! So, I found the problem, exactly, and I very gently ask you guys to follow through with a fix.. Please?

------------------excerpt from AddWrkfl.aspx ----------------------------------
if (m_bContentTypeTemplate)
        <input class="ms-input" Type=Text style="<SharePoint:EncodedLiteral runat='server' text='<%$Resources:wss,AddWrkfl_ListSelectionControlsStyle%>' EncodeMethod='HtmlEncode'/>" Title="<SharePoint:EncodedLiteral runat='server' text='<%$Resources:wss,AddWrkfl_TaskListName%>' EncodeMethod='HtmlEncode'/>" Name="TaskList" ID="TaskList" maxLength="255">
        <SELECT ID="TaskList" Name="TaskList" style="<SharePoint:EncodedLiteral runat='server' text='<%$Resources:wss,AddWrkfl_ListSelectionControlsStyle%>' EncodeMethod='HtmlEncode'/>" Size=1 align=absmiddle onchange="OnChangeSelectTaskList();">
       foreach (SPList list in Web.Lists)
        if (list.BaseTemplate == SPListTemplateType.Tasks)
        <OPTION value=<%SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(list.ID.ToString()),Response.Output);%>>
        <% SPHttpUtility.HtmlEncode(list.Title,Response.Output); %>
        <OPTION ID="OptCreateNewTaskList" value="" />

------------------excerpt from AddWrkfl.aspx ----------------------------------
Dec 11, 2008 at 7:52 PM
Sorry for the time it's taken to get this fixed.  We've both been on the road lately. 

The fix is actually deeper in our code and we've just made the change.  I'm currently testing the fix.  Once my testing is done I'll check in the changes and you can get the lastest version with the updated code.  I'll be running the system through our first layer of testing and then Wouter will be running it though a clean install on a full farm.  Once he is done we'll be releasing a new version.

I'll respond to your post when I have the fixes checked in.
Dec 11, 2008 at 8:24 PM
Ok thanks. Just to be clear, I wasn't suggesting that I thought the bug was in AddWorkfl.aspx, I'm fully aware that it's in AssociationPage.cs, but the post variable, TaskList, which was being used by that code to extract the task list from the boilerplate interface was coming from AddWorkfl.aspx.  From the stuff written on AddWorkfl.aspx, half the time that variable will contains a Guid, and half the time it contains a name.  I certainly wasn't implying there was something wrong with the boilerplate sharepoint code to be fixed or replaced by yours.  Just that it would need to be handled differently.  The code that you had in place was treating it as if it always had the name, and never handled the case in which it was a Guid, by accessing the Web.Lists[String] this overload of the Item indexer on the SPListCollection property "Lists," inestead of using the Guid version of the same.  That's probably what you fixed if you fixed it, but I wanted to be clear just in case it wasn't.
Dec 11, 2008 at 8:53 PM
Give the latest version of the code a try.  Hopefully it will fix your problem.  You should see a release in the next few days.

The problem was close to what you were suggesting.  Essentially all we needed to do was setup our code to not create the list for a content type association.  Instead of creating a list and attaching the actual SPList object, we should have been attaching just the names of the lists.  WSS handles creating the new lists when the first instance of the workflow is started on any given site.
Dec 12, 2008 at 4:28 PM
I really appreciate you guys coming through with this. I'll have to wait for your release though becaue the code signing requires a password and I'd have to create a new feature with all new ID's and take every file where you've referenced an assembly and tweak the PublicKey token, so instead, I'll just wait for the release with your public key signature on it, thus creating as little confusion/conflict as possible.  Thanks again though, I know how it is when someone who doesn't work for you and isn't paying you is the one doing the prodding, and I appreciate the help as well as the framework here. It's a great tool.