Open topic with navigation
WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
xcall I_ENABLE([D_FLDS,] window_id, field_list, …) xcall I_ENABLE(D_SET, window_id, set_name) xcall I_ENABLE(D_ALL, window_id)
(optional) Enables all specified input fields. (default)
Enables all input fields in a set.
Enables all input fields in a window.
The ID of the input window containing the field(s) to be enabled. (n)
One or more field specifications. (a)
The name of the set containing the field(s) to be enabled. (a)
I_ENABLE enables one or more fields in an input window. Input fields are enabled by default; use I_ENABLE to re‑enable fields that have been disabled.
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, birthday, soc_sec_no, employer, phone, policy_no, conditions"
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 enabled 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 are not enabled. To enable buttons you should use the B_ENABLE subroutine.
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:
If a break occurs on field A, and the code executed after the break enables field B, the next field processed is still field C because the context for the next input was determined before the break occurred. To access field B next, I_NEXT should be used.
If, on the other hand, field B was enabled within a leave method for field A, field B would be the next field accessed, because the input context for the next input is determined after calling the leave method for a field.
I_DISABLE for more information on disabling input fields.
The following example enables the fields state and zip.
xcall i_enable(inpid, "state, zip")