InfoPath Dev

I am attempting to develop forms a solution using InfoPath whereby I would need to be able to save off a copy of the original XML data created by the process of filling out a form, and a copy of the original form that created that data. At a later date, the user would need the ability to reopen that original form and data; possible on another machine (yes - all PCs will have InfoPath installed).

Problems with this that I cannot overcome:
1. The forms all have code behind them, and therefore must be fully trusted. I don't want to have to trust/untrust a form just so the user can view the data. In some cases, however, the user will need to be able to edit the information, and again, this means (according to what I think I know) having to register and trust that form, on that machine ... then unregister it when the user is done, so it doesn't step on another form by the same name ...

Am I barking up the wrong tree? Should I be using Word Smart Documents for this type of "application"?

In my case, it seems that the seperation of form from data is a bit of an issue ...

Please enlighten me, if you need more information than what I've provided, let me know.


D.

InfoPath forms seldom require Full Trust. As long as you are not trying to do things like write to the User's local hard drive you can write all kinds of code and not use Full Trust. What exactly are you doing in your code that requires Full Trust? Otherwise, I think InfoPath can accomplish exactly what you're looking for.

There are two parts to an InfoPath form: The template (.xsn file), and the data (.xml file).

For usere's to fill out a new blank template they will double-click on .xsn file that you have created opening the form ready to be filled out. When they are done filling out this form they will save the data as an .xml file. Double-clicking on this .xml file at a later date will open the form template and populate it with the data stored in the .xml file automatically. The only problem with opening the .xml file on a different machine than it was created would be that the new machine must have the .xsn file cached locally or available over a network. This can be done easily by publishing your forms to a SharePoint site or a regular network drive. Also, you could just give the .xsn file to the new computer, open it (therefore caching it), and then double-click the .xml file.

I think InfoPath will be able to do exactly what you have described, as long as you don't try to do anything too crazy with the code. Even if it doesn't accomplish exactly what you're looking for, I doubt that InfoPath is going to be more difficult than Smart Docs. However, you are a better judge of that than I.

I hope this info was what you were looking for!

---------------
Matt Faus
InfoPath Dev Texas

I am reading from a system registry hive to get a directory source where we'll save the resultant InfoPath data files.

...

Although your comment has given me an idea, if I use a secondary xml data source to pass that information along from our primary application to InfoPath, perhaps I can avoid having to have a fully trusted form?



D.

Unforunately, even using a secondary data source seems to yield either a message box prompting the user to give access to the form, or I have to Fully Trust and register the form (unless I'm outright "doing it wrong" - which I don't believe I am).

Other ideas?

D.

Hi Doug,

Word Smart Docs have to be installed too and, in general, are more of a deployment hassle than InfoPath forms.

I think the problem is the "saving the form's data". If the code is doing this programmatically, then it's a security hole and the workaround is to make the form trusted, aka Full Trust. If instead, you submit the form to a SharePoint library or some Web service using the default submit data adapters then you won't have to be Full Trust.

Do you have the code for the forms available? If so, I suggest you isolate the section that requires full trust and paste it in this thread. We can give you ideas for how to remove that requirement.

BTW: you don't need full trust to use a secondary data source (2DS) that you are reading from so long as the source is on a domain server or is part of the solution. To read a file from a local or remote file share is considered a security hole and therefore requires full trust.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Patrick -

Thank you for the information. Unfortunately, we cannot mandate the use of SharePoint, web services or even a domain for what we're wanting to do with InfoPath; we must develop this solution without the requirement for the end-user to purchase any additional 3rd party solutions. In other words, "we must make do with what they have". In this case, they all have Office Pro. installed with InfoPath; administration of services such as IIS and whatnot are a big No-No. Since these are generalized end-users and do not have IT admins to assist them; and our support group isn't about to take on that responsibility.

"Yes", I have to read from a local disk file to obtain some shared information between a client/server application, running Sybase, for that local machine and the InfoPath form itself; either that or a registry hive, but the end-result is the same: requires full trust. I do have access to a .Net ADO Data Adapter from Sybase, which I have not yet tried, mainly because that means managing log-in credentials between my InfoPath solution and the C/S application.

I recently realized that we're probably attempting to make InfoPath do something for which it was never intended/designed. I want to use InfoPath as the main "Forms Designer" application, but I need it to save the form out as if it were a word document (the form and data, in one, in the original layout, etc...)

I have come to the conclusion that I will either develop my own "Form Manager UI", so I can track forms, reg/unreg them, etc...

or

Come up with "view only" solution that can be used on the resultant XML ... but because of regulations in my industry, I seriously doubt this is an option.

D.

Hi again,
Thanks for the eloquently worded, thoughtful response. in your original post, you said something about needing to unregister the form due to a concern about it colliding with another form. Not sure what you mean by this and I'm guessing it is not an issue.

Full trust seems fine given your scenario. You could also look at submitting the form to a file share and thereby forcing it to be domain trust.

In general, I don't understand your concern. InfoPath is a good product. The major issues are that coding is often required (whereas the guidance from MS is that it is not required) and the fact that performance sucks for certain scenarios (but there are ways to mitigate that). Deployment is tricky and more difficult with full trust, but in general, this is not a showtoppper.

Three reasons not use InfoPath:
1. Rich document -> use Word
2. Spreadsheet like calculations -> use Excel
3. Reporting client -> use SQL Reporting Services

For your issues, I don't see the problems, but perhaps I still don't understand the issues.


Patrick Halstead [InfoPath MVP]
InfoPathDev