(re-posted from a blog post on our private intranet...)
"Single Submit:disabling submit functionality in InfoPath"
Forms developed in InfoPath for browser-SharePoint library
interaction generally have a submit button to send the xml file to the
library. Occasionally, this submit button needs to be disabled; maybe
until fields are filled out, or so users don't accidentally hit it more
than once after it's been submitted. Usually, a clever bit with a
hidden field in the data source, a rule, and some conditional
formatting will solve this error. For those not familiar, the set up
is:
- Have a hidden field (i.e., in the datasource but not on the form user interface) set to a default value of show, enabled, 1, etc.
- A rule that stipulates once the submit button is pressed, change the value of the hidden field to the opposite value; hide, disabled, 0, etc.
- Conditional formatting on the button that says when the hidden field is equal to disable etc., either hide or disable the button.
- (this can also be done programmatically, which prefer, now that I'm an incipient programmer)
And this is likely fine if end users have no need to reopen the xml
form once it's been submitted to a SharePoint library. Because once you
open the form, the value in that hidden field is reset to the default.
I'm not sure what causes this, but it was the source of my agony for my
latest form, because very occasionally, an InfoPath form's
functionality calls for the ability to not only submit a form, but to disable the submit as well.
The last form I created needed to submit the first time, but not the
second, third, or other times opened. And an added hitch: it had to be
a solution through the InfoPath designer user interface, not managed
code. (…Because forms with managed code need to have full trust, which
needed to be uploaded through central admin, which don't play nice
(read: don't work at all) with the versioning history capability that
was also necessary on this form)
Here is my solution:
- A submit connection to my SharePoint library.
- Unique file names that do not overwrite built into said submit
connection. (I used an xpath formula builder to concat a few of fields
in the form)
- A secondary data connection to receive data from the library where
the forms are submitted. (Specifically, retrieving the unique file
name)
- On the form, I have an expression box set to the value of the unique file name (through secondary data connection)
- Conditional formatting on my button that stipulates when the unique
file name field in my secondary data source is equal to the xpath in
2), to hide/disable the button.
Viola! A form that has a submit button at the bottom during the
first instance of opening, but disappears the subsequent instances.
(It's
also worth noting that this technique only works on the current form.
If I hadn't needed the versioning capability, I might never have
discovered I had to change a setting inside my receive connection [to
get the unique file name]. I unchecked the "Include data for the active
form only" on the third screen of the data connection wizard, and then
it worked beautifully.
Happy Developing!