ufv_settings usage details

All ufv_settings can be changed by computes in the form. The following example shows how a form can be set to read-only using a compute. In this example, the custom option opt_1 will set modifiable to off once the form has been submitted.
```
   <button sid="SubmitForm">
      <value>Submit Form</value>
      <type>submit</type>
      <custom:opt_1 xfdl:compute="toggle(activated,'off','on') == &#xA;
         '1' ? set('global.global.ufv_settings[modifiable]', &#xA;
         'off'):''"></opt_1>
   </button>
```
Note that the ufv_settings option is a form global option in the XFDL namespace, and is referenced using the following syntax:
```
   global.global.ufv_settings[element][setting]
```
For example, to reference the setting for the Open control bar button, you use:
```
   global.global.ufv_settings[menu][open]
```
submitwithformaterrors
Important: If you are using an XForms submit, submitwithformaterrors is not evaluated.
validoverlap
- The overlap test looks for signed items that overlap unsigned items. You should always follow the best practice of signing as much of the form as possible. This means that if your form is failing the overlap test, you should first consider whether you can sign additional items to correct this problem.
- Lines can often cause problems. In general, you should either sign all lines in the form, or sign none of the lines in the form. This will help you avoid problems with lines that overlap each other. If you choose to sign none of the lines in the form, you may need to adjust the placement of some lines to prevent them from overlapping with other items, such as fields. While this may seem like a lot of work, it's preferable to signing the overlapping line. Signing the line may create more problems than it solves, as the line may overlap with a number of other lines, which may overlap with further lines, and so on. Because of the work involved in determining which lines need to be signed, it's best to avoid this scenario if possible.
Because the unsigned items might be moved later to reveal information that changes the meaning of the form, the overlap test prevents the user from signing these forms. However, in some cases the overlap is very slight, and should be allowed. If you still find that you cannot sign your form because of overlapping items, you should adjust the validoverlap setting by small increments (such as 1 or 2 pixels) until you can successfully sign the form or until you reach an overlap of 8 pixels.

Note: Never set the validoverlap to allow more than 8 pixels of overlap. If you find that you still cannot sign your form with an overlap of 8 pixels, you should redesign your form so that the items do not overlap as much. Using a larger validoverlap increases the risk that a malicious user could successfully modify a signed form.
The validoverlap can be set as low as 0 pixels. The default of 2 pixels accounts for the size of a border, which is included in the size of each item even if the border is not drawn.
The appearance of the helpcursor relies on the Window settings. Individual users can use those settings to change the appearance of the cursor.
The following settings exclude error assessment for XFDL items that have the applywithinvisble set to off:
- pagedonewithformaterrors
- signwithformaterrors
- submitwithformaterrors
- printwithformaterrors
The following settings do not affect predictive type checking:
- printwithformaterrors
- savewithformaterrors
- submitwithformaterrors
- signwithformaterrors
When these settings are in use, type checking will continue to occur as the user types.
Disabling scrollfieldsonzoom may limit the functionality of the form when the user zooms. This feature overrides any setting in the Viewer's preferences form. Use this feature only in the form global setting; it does not work in the page global setting.
The focusbgcolor and focusfontcolor options are only available forIBM® Forms Server – Webform Server.