InfoPath Dev

Hi, I hope this isn't too basic, and a question that's been answered many times before.  I searched the site and couldn't find a comparable answer.

 I'm testing out the QRules product, and when trying to publish a form as a browser based form, I get a message at publishing time that the form cannot be published as a browser form.  The design checker then comes up with absolutely no issues listed.  So, I went back to basics, created a blank browser form (not injected) and published.  No problems.  I then created a blank browser form and used the QRules injector tool, then tried to publish.  I get the same warning at publish time, and the form won't display in the site.  If I publish as an InfoPath Filler form, it opens in InfoPath without issue.

 Here's my issue in a nutshell:  There are very few users in our organization that have Filler, much less Filler 2010.  We want to make electronic forms fully functional, and accessible to as many users as possible without requiring licensing for Office 2010.

What am I missing?  Thanks for any help.

Hi Tom,

Can you check whether you are a Site Collection Admin?

Since the form is injected with qRules it requires going thru the Sandbox publishing service.

If the form is not publishable, it's because
(a) the sandbox service isn't running

(b) you're not a site collection admin.

I think, however, that you would get a different message if the sandbox service wasn't running on the server.

Let us know what you find. Thanks.

Thanks for the reply, Ernesto.

 The site I'm publishing to didn't have me as a Site Collection Owner, so I fixed that, and Sandbox publishing wasn't on either.  The form publishes fine and displays after that.  I checked the User Guide and didn't see anything that said Sandbox Publishing was a requirement.  Maybe I missed it.

 My concern is how will forms display to users other than me?  Will a security message display prior to the form rendering?  I'm wanting to avoid that.

OK, I just published a test form using the instructions in the Quick Start guide.  This is the one that uses the DateDiff command with a couple of date pickers, a result textbox, and a button with a rule applied.  It works great in a Filler environment, publishes just fine as a web browser form, and displays without issue.  However, the rule doesn't fire.  No results.

 What else am I missing?

Hi - you'll need to set postback on the control bound to the field that executes the command to "Always". Right click the control and select the properties. Under the browser tab, change postback to always.

Thanks Hilary, that did the trick.

 Is this true for QRules in general?  In other words, for control based rules, should postback always be on?  I noticed there was a bit of delay while the data was sent to the server.  Any ways to speed that up?

 I know I'm being picky, but I'm trying to give a fair evaluation of the product to see if it's worth purchasing.

This is true for qRules in general - when we set the value of the command field, the data has to post back to the server in order for the code to execute.

Postback in browser forms does cause a delay.

I try to group my logic when possible (i.e. perhaps instead of caclucating a date diff when a field value changes, it could be done right before the form is submitted or when the XML is reloaded, etc) to prevent too many postbacks.

I'm not sure what can speed up the actual postback itself - I imagine some of it would have to do with the general configuration of the SharePoint server itself, and the speed of the network connection between the client & server, as well as the client machine config in terms of speed for re-rendering the form, but I'm just guessing on all of these.

Edited to add - you aren't being picky, you are doing your homework before your buy - that's why we have a trial, so keep the questions coming! :)

Thanks again Hilary.  I'm now tediously navigating all the available commands.  Lots to consume.  At some point, I suppose the best course of action would be to test using the provided test form and see if I can incorporate into real world scenarios for our organization.

We're looking to replace a proprietary electronic forms engine with our own development using InfoPath browser forms.  That's why we're going down this path.  Just wait until I start going down the workflow path!

The sample form demonstrates a lot of the commands - but doesn't display what I consider to be the real power of qRules. The real magic happens when you start combining the commands together.

I think of the commands as building blocks - each little one may not seem to do much, but you can combine them to pretty much do away with custom code in your forms.