I_DISABLE

Disable input fields

WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
xcall I_DISABLE([D_FLDS,] window_id, field_list, ...)
xcall I_DISABLE(D_SET, window_id, set_name)
xcall I_DISABLE(D_ALL, window_id)

D_FLDS

(optional) Disables the specified input fields. (default)

D_SET

Disables all input fields in a set.

D_ALL

Disables all input fields in a window.

window_id

The ID of the input window containing the field(s) to be disabled. (n)

field_list

One or more field specifications. (a)

set_name

The name of the set containing the field(s) to be disabled. (a)

I_DISABLE disables one or more fields in an input window.

On Windows, the disabled fields will be grayed and unable to receive keyboard focus either by mouse click or by pressing Tab/arrow/Return (Enter).

You can specify up to nine field lists (field_list arguments), each of which can have from one to nine field specifications. If a field_list has multiple field specifications, separate the field specifications with any character except alpha characters, numeric characters, dollar sign ($), underscore (_), and square brackets ( [ or ] , which are used to enclose dimension specifications for repository arrayed fields). For example:

"name"

or

"name, birthday, soc_sec_no, employer, phone, policy_no, conditions[2]"

The maximum length of a field_list is 99 characters. Additional characters are ignored. For information on field specifications, see Field specifications.

If any of the designated fields are not contained within the window, a fatal error occurs.

When using D_SET, it is important to remember that the field remains disabled even when you are not processing the set to which you applied D_SET. This is because enablement is a field-specific attribute. When using D_ALL, it is important to note that buttons aren’t disabled. To disable buttons you should use the B_DISABLE subroutine.

Calling I_INPFLD on a disabled field returns immediately.

Note that when a break occurs in input processing the input set context for the next input has already been determined. Thus, altering the enabled state of a field in the set during break processing will not alter the input set context, even if you are enabling the field that would have been processed next. You must call I_NEXT to alter the context in any way. For example, consider the following scenario: An input set consists of fields A, B, and C. Field C is a break field. The user keys a value into field C and terminates by selecting the menu entry I_PREV, which creates a break. In the break processing, field B is disabled. The next field accessed is field C again, because the I_PREV logic had targeted field B as the next field to process. When it came time to process it, field B was disabled, thus field C was accessed instead. If, on the other hand, field B was disabled within the leave method for field C, then field A would be accessed next, because the input set context is determined after the leave method is called.

The following example disables the fields state, addr[2], and zip.

xcall i_disable(wndid, "state, addr[2], zip")