I have had some strange behavior in InfoPath with numeric fields that became locked even if they were not configured to be read-only. These fields were never locked when using the form to enter new data, but sometimes when modifying existing data.
After a bit of investigation, I found out that when an element in the XSD has e.g. default="0" and the user does not change it to something else, then this value will not be included in the XML when submitting to the web service. When the user later on opens the saved data, the element will not be in the XML returned by the web service. This will cause InfoPath to lock the field in the form, as InfoPath cannot bind to an element that is not there. This is very annoying, and setting default values in the InfoPath form will not make this go away. A field that contains a value different than the XSD default value, will be in the XML and thus fully editable.
In short, do not use the XSD default attribute in schemas intended for usage with InfoPath. It is sad that a client application imposes its weaknesses on the contract schema design, but the best is the enemy of the good, so I changed the schema to suite InfoPath.
Note that I have only tested this in combination with a WSCF web service.
1 comment:
We noticed the same behavior (missing fields in XML docs returned by Webservices). We tracked this down to the Enterprise Library's Database Datatable to XML conversion. Any null values in a recordset are not converted to empty fields in the resulting XML, but rather they are just omitted. Our solution was to use the schema to build ourselves an empty instance document and populate it with the data from the recordset. This way we are guaranteed to get all required nodes returned from a webservice
Post a Comment