InfoPath Dev

I am implementing a solution for InfoPath form packages, in this package we have a main form, let's call it FormM, and some Associated Forms let call them FormA1, FormA2,.....FormAn.

Requirements

1) Our users wanted to be able to *open and create new* FormA1, FormA2,..etc from the FormM,  

2) Our forms cannot be a filler form as the client users want to be able to open them within browsers from locations where there is no InfoPath and open the forms in Filler whenever it is available.

The Action of Filler form could do things like opening another form, and we could have links in browser forms, but how could one get them work both in Filler as well as in browser?

What would you suggest as a solution? Thx

I wonder about using a Filler only view - in the view properties, you can check a box indicating a view is for Filler only. If you write code (or use qRules - it has a command for this called GetEnvironment) you could ascertain the environment the form was opened in and switch to the Filler only view....

Filler only view won't work as our client wanted to support users who have NO office 2010 and Filler installed, Some of them are these who are walking around and holding a iPad2/3 in their hands:)

Also even with Fill only View,  you would need a link to open an existing form, right?

I was suggesting multiple views. One view to be used in the browser. One view to be used in Filler. Your original question stated:

The Action of Filler form could do things like opening another form, and we could have links in browser forms, but how could one get them work both in Filler as well as in browser?

So, I was assuming in your filler only view you'd use a button with an action that opens a new form - and in browser you'd have a link.

Hmm, I thought Filler Form vs Browser Form is a form level Compatibility option, not a view level setting, am I misisng something? I didn't find anything in the View Property.

Thx

I've attached a screenshot - it is under the view properties for a given form view.

I see.  So the Filler only view will be rendered only in the filler and not rendered when edit in browser?  Our forms already fairly complicated and had to break down into separate views, have more views may hurt the performance further. 

Another question I have is if you create a new form formA1 from main form FormM and submitted it, is it possbile to carry on information from FormM to populate certain fields of FormA1? from I read online, this is not possbile; and whether we could feed the user input from the FormA1 back into the FormM? or get the URL of new FormA1 instance saved into FormM.

Thx

The filler only view is available only in filler - I imagine if you want the form to automatically switch to that view, you would have to include the logic for that - although you may be able to set it as default and the browser will automatically use a different view for the default - not sure on that - you'd need to experiment a bit.

If you submit Form A1 someplace that Form M can get its data, you could have a data connection in Form M that could requery - I'm not sure what you'd trigger that on - probably have to put it on the user via a button.

Interesting idea!, thanks...to make the idea work for us though we may need to figure out a way to do this:

In our project, the FormM is called ProjectForm, and FormA1 could be BudgetForm,  one thing we need to accomplish is passing the ProjectID from ProjectForm over to the BudgetForm, is it something that is doable when the ProjectForm is a Filler form?

Thanks

Wei 

You can use input parameters with Filler forms. More here.

Looking back at your original question - why not just make everyone use the form in the browser?

Wanted to add one more thing - if you host your child forms in a form viewer web part (browser only) passing in a parameter can be done w/out code. Here's a cool blog post on that.

Hi, Hilary:

Thanks for all the interesting reads. the reason we didn't choose a browser only route, was the features richness of InfoPath Filler form, and the featues that stood out were the Spell Checker functionality and smoother formating of Rich Text control.

Wei