1

I've recently been doing support work for few solutions built with browser-based InfoPath forms. And all of the solutions have had a large amount of customization using code-behind.

So far I've only seen one code-behind file (FormCode.cs) used for each form. Is it possible to organize (re-organize in my case) the code into multiple files?

Improve this question

2 Answers 2

Reset to default
2

A bit late, but since the other answer was not terribly helpful, you can reference other classes and code in a separate strong-named assembly and include a reference to it in your project. The form's assembly may be fairly rigid, but you can always design around it. Build your other functions/classes in a separate VS project, deploy it as a SP solution, and then target your form against that.

Improve this answer
8
  • Infopath forms are client based. It is not fixed where and how they will be deployed/published and used (from client). Have you practically succeeded in packaging multiple assemblies in one Infopath XSN template?
    – Gennady Vanin Геннадий Ванин
    Oct 3, 2012 at 1:25
  • I am still not grasping. Code-behind is the term used for code created in MS Office VSTA as client code (except through IPFS). It is deployed from client and get from published location to run in client/filler form. How did you manage that code run on client have used assemblies on another computer, if it is not packaged in Infopath template?
    – Gennady Vanin Геннадий Ванин
    Oct 3, 2012 at 8:43
  • The original poster is speaking to IPFS forms, not forms that will run in the InfoPath client. In IPFS, the server is running the code and you can deploy additional assemblies into the GAC for your project to reference. You may be able to reference them from /bin but I have not tried this as the GAC was generally the solution I had to go with.
    – Drew Lanclos
    Oct 4, 2012 at 17:05
  • Oh oh oh. Just realized this - I have worked with a client form that used external assemblies as well. You build it in a separate project and either have the output go into your InfoPath Form Template folder, or manually copy the DLL and PDB into the folder. Add it to the InfoPath Form Template solution folder, and the reference required in manifest.xsf goes like so: <xsf:file name="My.Assembly.Name.dll"><xsf:fileProperties><xsf:property name="fileType" type="string" value="refAssembly"></xsf:property></xsf:fileProperties></xsf:file>
    – Drew Lanclos
    Oct 4, 2012 at 17:10
  • 1
    At any rate, to your question, you can't prevent it completely (the user needs read access to the location where FormServerTemplates resides and can theoretically open the template there), but from 2010 onward, you can tell the list to default to opening a browser-enabled document server-side. (List Settings -> Advanced -> 3rd option down.) You can use Jquery to remove the "Edit in Microsoft InfoPath" selection in the ECB menu. You can also use code-behind to restrict the form's operation so that it refuses to function in client mode.
    – Drew Lanclos
    Oct 5, 2012 at 18:00
1

The FormCode class is a partial class. You can add multiple code-files to organize so long as they are partial FormCode classes as well (edited per first comment).

It is possible to have embedded classes under FormCode also.

Improve this answer
7
  • Ah, very true, forgot that bit, I was just looking at some old projects to see what made them possible. Idea still holds true, though. Partial classes will allow you multiple code-behind files.
    – CMN
    Oct 2, 2012 at 2:07
  • I did not downvote but your idea will make normal and intended by design usage of Infopath form impossible, if it is possible at all
    – Gennady Vanin Геннадий Ванин
    Oct 2, 2012 at 2:27
  • Why would it make the intended usage of InfoPath impossible? Adding additional code files to the project doesn't break anything. Using partial classes is all the same to the compiler. I knew my above idea worked no problem from past experience, and have just tested to subclass method to prove it works as well. While I will agree that if you have to put code-behind in your InfoPath forms you're likely going to have to have a bad time, it was part of the original question. It was a situation the poster inherited, not one he was designing.
    – CMN
    Oct 2, 2012 at 3:22
  • 1
    public partial class FormCode { public class SubCls { public void SetField(XPathNavigator x, XmlNamespaceManager m) { //Set Field } } } SubCls would be the subclass I was referring to. With this setup, I can now do something like "SubCls c = new SubCls(); c.SetField();"
    – CMN
    Oct 2, 2012 at 12:48
  • 1
    Thanks. Ypu could have added formatted code to your answer. This is probably not subclass (FormCode cannot be inherited/subclassed since it is a sealed class), it is embedded class
    – Gennady Vanin Геннадий Ванин
    Oct 2, 2012 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.