What I want to talk about after being tortured by infopath

The knowledge points and content involved in infopath forms when working together with workflows are a little complicated. Naturally, various errors are generated, and I often feel inexplicable about these errors, as a matter of fact, we did it step by step according to the reference materials. Why am I wrong? In this situation, I am as confused and helpless as everyone else. I even try my best to capture my head, and my mind is like a cat. But then we have been tortured, the more anxious the problem cannot be solved, the more difficult it is. In fact, as long as we calm down and carefully adjust the problem from start to end, we can still solve the problem quickly, the key is to have patience and perseverance, and then add a little bit of understanding. Don't be intimidated by difficulties. Well, we have a lot of questions. I haven't done WF for more than half a year, and this time I went back to the old business. I didn't have enough skills when I was studying it. This time I vowed to have a deep understanding. Not to mention the depth of understanding is also due to a painful torment. to combine infopath and WF, we often need to design the corresponding WF process and place the infopath form we need on each node of the specific process for association, this inevitably involves the design of infopath forms. I believe I have learned a lot about infopath. Here I will summarize my personal experience, first, open the infopath designer to design the form. First, select a design template that meets our needs and ensure that only the browser compatibility function is enabled, because our form is to be opened in the browser, this can avoid some features not supported by the browser. When the form is opened, we can design some fields, attributes, and so on, establish related data connections and so on. After we have designed these data connections, we will go through two processes: storage and release. Before saving the file, confirm the compatibility settings of the browser. It must be an infopath template that can be opened in a browser. For version control, we need to select automatic upgrade first with a form so that we can automatically update the version at the time of release. The key is security and trust, it largely determines whether your infopath form can be successfully published. Because I am working with WF, you can select the domain trust level or full trust level. Here I select full trust. You can set other settings as needed. In this way, we have completed the infopath settings, and then we can release our infopath to the file storage location of our project. after doing this, we usually need to export the XSD Schema of infopath and generate the source code required by WF through schema. This requires the help of XSD tools, we will add the generated soucecode to our project and deploy it in moss or other hosts. Through this, the host can make infopath communicate with our WF, in WF, we can get the field value we need. What will be done in WF in the future will be what your WF is doing. Speaking of this, I just mentioned some settings and basic development processes that need to be done in the collaboration between infopath and WF. In the meantime, I also took a lot of detours and encountered many errors, in fact, most of them are still on infopath, so when developing infopath, pay more attention to infopath settings. After all these operations are completed, we can modify the released batch files so that they can be released to the correct location for deployment, the WF description file must contain the corresponding assembly and class descriptions. The most important thing is not to forget to add a Sn to your WF, finally, run and deploy the BAT file to install and deploy feature and GAC. Don't think that your WF can work now. You have not yet. You need to activate it in Moss, then, associate in the required list. Then, your WF can be used. Start and see if your WF form design is presented. I hope you will make fewer mistakes.

The following information about code-bebind form errors is displayed on the Internet. If you are interested, take a look:

SharePoint workflows-infopath 2007 form 'code-behinds'

After taking a bit of a break from workflows to attend to other aspects of moss mizmization, I'm preparing to get back into it. In digging thru some old files
 
After taking a bit of a break from workflows to attend to other aspects of moss mizmization, 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 our 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

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

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

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