Prevents the value of a field from being 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.
NoAccept(att | &var) [ IF condition ][ ON triggering event] ;
Where:
att | &var
In Web Panel objects and Panel objects only variables are editable. So, in those objects, this rule can be used for variables. In Transaction objects, attributes are editable. So, mostly this rule is used for attributes. Variables are accepted in Transaction if you define Accept rules.
condition
Is the condition that must be met to trigger the rule.
triggering event
See Triggering events for rules in Transactions.
Objects: Transaction,
Web Panel,
Panel,
Work Panel
Generators: .NET,
.NET Framework,
Java, RPG, Cobol, Visual FoxPro (up to GeneXus X Evolution 3), Ruby (up to GeneXus X Evolution 3)
The NoAccept rule doesn´t allow the end-user to change the value of a field. In most Environments, this means that 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), then that input value is ignored.
GeneXus evaluates which Attributes/Variables are used for input/output. However, there are times when you do not want the end-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 input fields. The rule may also be used in combination with conditions.
All variables that appear in a Web Panel object or 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.
When you declare this rule, you will be able to assign a value for the attribute or variable with another rule.
NoAccept(ProductDescription); // Unconditional NoAccept
NoAccept(CustomerCreditLimit) if CustomerCategoryId = 1; // Conditional NoAccept
Notes:
- &var could be an 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 {att|&var}.Enabled = 0 assignment for the No Accept condition and {att|&var}.Enabled = 1 for the otherwise section.
- If you take the conditional rule of the previous example, you will see in the following code the Navigation view of the object:
One condition:
Rule:
NoAccept(CustomerCreditLimit) if CustomerCategoryId = 1;
Navigation View:
CustomerCreditLimit.Enabled = 0 If CustomerCategoryId = 1; 1 OTHERWISE;
This means that the rule will disable the CustomerCreditLimit attribute only if the value of the attribute CustomerCategoryId 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, you must be careful with the conditions defined in each one, as they can cause conflicts between them.
Enabled property