Expand my Community achievements bar.

SOLVED

Strange validation behaviour with "User Entered - Required" fields

Avatar

Level 2

I have a situation where I have a form with several "User Entered - Required" text fields.  Some of the required fields are prepopulated by a server process before being presented to a user in Workspace.  When the user fills out the remaining required fields and submits the form (by clicking on the "Complete" button in Workspace), the standard "required fields" validation message appears, even though all of the required fields contain data.

The form where I discovered this problem is moderately complex, so I built a simple form and process to try and figure out what is going on.  The simple form contains exactly two text fields, both are User Entered - Required.  Field A is prepopulated by a server process when the associated workspace task is invoked, Field B must be filled out by the user.  There is no custom script beyond the Form Bridge and a single Submit button.  It is about as simple as it gets.

If Field A is prepopulated, and then the user fills out Field B and clicks "Complete", the message appears saying "At least one required field was empty...", even though both fields contain data.

If I go back to the form and delete Field B (and redeploy the form, and reinvoke the process), Field A is prepopulated and the user clicks "Complete", no message is displayed and the form is submitted.

As far as I can tell, the built-in validation for required fields works fine only if all of the fields are prepopulated, or none of them are prepopulated.

Can someone explain what's happening?

EDIT: I forgot to mention, I also created and configured Preview Data for the simple form.  The preview data only contains a value for Field A.  When viewed in Designer's Preview tab, everything works as expected.

1 Accepted Solution

Avatar

Correct answer by
Level 2

A after a bit of grunt work I have a better understanding of what is going on, and a solution.  I scripted several calls to xfa.host.messageBox(...) on various events.  Turns out that the pre-populated fields are not the culprit - they have values as expected.  The trouble is with the non-pre-populated fields, and and a subtle behaviour of the event model that causes a problem when using the Workspace UI (at least on ES3).  Field values don't seem to be set until a field loses focus (e.g. when a user tabs to another field, or clicks a button).  In a form used outside of Workspace, clicking on a Submit button causes the focus to be shifted to the button, which causes the entered values to be bound to the fields.

Solution: Use an Indirect Submit button on the form, and in the indirect submit's click handler use (in addition to your normal code):

xfa.host.setFocus(null); 
xfa.resolveNode("[[fully qualified name of the real submit button]]").execEvent("click");

Workspace should then detect you have an Indirect Submit button and execute the associated click handler, which in turn invokes the form's real submit button.

Here's where the next bit of fun begins: there's a bug in the Form Bridge code (at least in the ES3 version) that prevents it from detecting Indirect Submit buttons when using JavaScript as the language on the button's click handler and

Here's my hack to solve that issue:

  1. Open the "ContainerFoundation_JS" script in Designer's Script Editor
  2. Ignore the warning at the top of the file
  3. Find the function named: isIndirectSubmitEvent (it's on line 1512 or something)
  4. Change the line that reads:
    • if (script.indexOf(button.name + ".execEvent") != -1) {
      to:
      if (script.indexOf(button.name + ".execEvent") != -1 || script.indexOf(button.name + "\").execEvent") != -1) {
  5. Save and deploy the form

If there's a better way to accomplish this, please share.

View solution in original post

1 Reply

Avatar

Correct answer by
Level 2

A after a bit of grunt work I have a better understanding of what is going on, and a solution.  I scripted several calls to xfa.host.messageBox(...) on various events.  Turns out that the pre-populated fields are not the culprit - they have values as expected.  The trouble is with the non-pre-populated fields, and and a subtle behaviour of the event model that causes a problem when using the Workspace UI (at least on ES3).  Field values don't seem to be set until a field loses focus (e.g. when a user tabs to another field, or clicks a button).  In a form used outside of Workspace, clicking on a Submit button causes the focus to be shifted to the button, which causes the entered values to be bound to the fields.

Solution: Use an Indirect Submit button on the form, and in the indirect submit's click handler use (in addition to your normal code):

xfa.host.setFocus(null); 
xfa.resolveNode("[[fully qualified name of the real submit button]]").execEvent("click");

Workspace should then detect you have an Indirect Submit button and execute the associated click handler, which in turn invokes the form's real submit button.

Here's where the next bit of fun begins: there's a bug in the Form Bridge code (at least in the ES3 version) that prevents it from detecting Indirect Submit buttons when using JavaScript as the language on the button's click handler and

Here's my hack to solve that issue:

  1. Open the "ContainerFoundation_JS" script in Designer's Script Editor
  2. Ignore the warning at the top of the file
  3. Find the function named: isIndirectSubmitEvent (it's on line 1512 or something)
  4. Change the line that reads:
    • if (script.indexOf(button.name + ".execEvent") != -1) {
      to:
      if (script.indexOf(button.name + ".execEvent") != -1 || script.indexOf(button.name + "\").execEvent") != -1) {
  5. Save and deploy the form

If there's a better way to accomplish this, please share.