After taking a bit of a break from workflows to attend to other aspects of MOSS customization, I’m preparing to get back into it. In digging thru some old files, I found some notes I had made about embedding .NET code in your MOSS Workflow InfoPath forms. I thought I’d post it in case it might help anyone out…
The ability to use InfoPath 2007 to create your workflow forms is one of the nicest features of custom MOSS workflow development. To make your forms even richer and more powerful, you can add ‘code-behind’ logic to your form using .NET code.
Overall, its pretty simple to write code for an InfoPath form, and that topic is covered very well in many other places, so I won’t go into any detail here. But what I will do is point out a few things I’ve learned about using InfoPath code behinds in MOSS workflows.
1. You don’t need an association form
a. Just comment out the tag from workflow.xml
a. Just comment out the tag from workflow.xml
2. If you have any control event handlers in you IP code-behind that require a postback, you’ll need to set the control’s Browser forms postback setting to “always”
a. Under Browser forms tab in the control’s properties dialog
b. Example, you have an event that fires when a dropdown value changes
a. Under Browser forms tab in the control’s properties dialog
b. Example, you have an event that fires when a dropdown value changes
3. If you are going to access the SharePoint object model in your code, you’ll need to sign the form to make it fully trusted
a. You don’t need to sign the form unless your code-behind accesses the SharePoint object model
a. You don’t need to sign the form unless your code-behind accesses the SharePoint object model
4. You’ll need the code-behind .dll file to live in the Feature directory folder, alongside the .xsn file
a. Not sure why having it in the GAC doesn’t do the trick
a. Not sure why having it in the GAC doesn’t do the trick