NoAccept rule

Prevents the value of the field to be changed by end-user interaction. In most environments, this means the field is disabled (no end-user input is allowed) when the condition (if any) applies.

If user input cannot be disabled (Business Component, iSeries, for example), the input value is ignored.

Syntax

NoAccept({att | &var}) [ IF condition ][ ON triggering event] ;

Where

condition
   Is the condition that must be met to trigger the rule.

triggering event
   See the information here.

Description

GeneXus evaluates which Attributes/Variables are used for input/output. However, there are times when you do not want the user to enter data for what GeneXus considers to be an input Attribute/Variable. This rule enables you to define which will not be used as waiting input fields. The rule may also be used in combination with conditions.

All variables that appear in a Work Panel object or Web Panel object are always by default input variables (i.e. they accept input) unless a NOACCEPT rule has been defined for it. Hence, this rule indicates that the variable must not be accepted; you will be able to assign a value for the attribute or variable with another rule.

Examples

NoAccept(PrdDsc); // Unconditional NOACCEPT

NoAccept(CreditLimit) if CliCat = 1; // Conditional NOACCEPT

Notes

• &var could be a SDT variable and in this case just writing NoAccept(&var) is enough to disable all the SDT elements.
• Conditional Noaccept: You must be able to evaluate the condition before the attribute/variable in the NoAccept rule is entered. That is, the attributes/variables involved in the condition must have a value before the rule is triggered. Conditional NoAccept is only valid for transactions.
• NoAccept rule over Primary Keys does not apply to Business Components methods (Load, Insert, Update, InsertOrUpdate).
• The NoAccept rule is expanded at specification time as a {att|&var}.Enabled = 0 assignment for the No Accept condition and {att|&var}.Enabled = 1 for the otherwise section.
  if we take the conditional rule of the previous example, we will see in the Navigation view of the object the following code:

One condition:

RULE:

NoAccept(CreditLimit) if CliCat = 1;

NAVIGATION VIEW:

CreditLimit.Enabled = 0 IF CliCat = 1; 1 OTHERWISE;

This means that the rule will disable the CreditLimit attribute only if the value of the attribute CliCat is 1, otherwise, it will remain enabled.

More than one condition:

RULE:

NoAccept(CustomerDiscount) if CustomerDate > Today() and CustomerActive = false and CustomerAmount = 0;

NAVIGATION VIEW:

CustomerDiscount. Enabled = 0 IF CustomerDate > today() and CustomerActive = FALSE and CustomerAmount = 0; 1 OTHERWISE;

This means that the rule will disable the CustomerDiscount attribute only if the value of the attribute CustomerDate is < Today() and the value of the attribute CustomerActive = false and the value of the attribute CustomerAmount = 0, otherwise it will remain enabled.

If you have different conditionals NoAccept, we must be careful with the conditions defined in each, because they can cause conflicts between them.

Scope

See Also

Enabled property