The validation methods allow the programmer to verify that
certain conditions are fulfilled before an action is executed.
In Axapta, methods of validation at two levels can be programmed:
1.
Table
2.
Origin of data of a form
It is important to know that the
methods of validation of the tables are executed whenever they are introduced
or erase registries. Whereas if the validation is made in the form, it will
only work when we are working with that form.
1.
Whenever it is possible,
the validation of data must be made in the table.
Methods
The methods of validation in tables are the following ones:
ValidateField
It is executed when we move the cursor from a field from the
form to another one, that is to say, when we left a field. It gives back a data
of boolean type. If the result is false, the cursor will remain in the field.
The call to the super method () verifies
the validation relations, that is to say, relations in a field where the Validate property
has affirmative value. Therefore, we must respect the task made by this super method ().
1.
Validations do not have to be codified that can be made with
some property. Thus, we will avoid to write code in the ValidateField method if
the conditions can be verified with the Validate property of a relation.
ValidateWrite
It is executed before inserting or updating a registry in the
table. It gives back a data of boolean type. If it gives back false, the
registry is not inserted or updates.
The call to the super method () examines
all the fields to verify the value of the Mandatoryproperty.
Therefore, we must respect the task made by this super method ().
1.
We will avoid to introduce code that it verifies if a field has
value, whenever we pruned to use the Mandatory property.
ValidateDelete
It is not necessary to forget, that often also we want to verify
certain conditions before erasing a registry of a table. In order to do this,
we used the ValidateDelete method ().
ValidateDelete () is called automatically from forms and is used
to verify if the present registry can be erased.
The call to the super method () verifies
if there are registries related in tables toDeleteActions of
the Restricted type. If that is the case, the super method () gives
back false. Therefore, we must respect the task made by this method.
1.
Whenever we pruned to use a DeleteAction, we will avoid to
introduce code in the ValidateDelete method.
Structure of the validation methods
In order to maintain a good structure of programming, he is
recommendable that the code for the verifications is not located directly in
these methods of validation. It is more advisable than we create verification
methods that will be called from the methods of validation previously
described.
Example of validation method
Boolean validateWrite ()
{
Boolean ret;
ret = checkSomething () && checkSomethingElse ();
return ret;
}
When some of the conditions is not fulfilled, the verification method must make
two things:
1.
to present/display to the
user an error message
2.
to give back the false
value like result
The
CheckFailed method (`Message of error') writes the
text chain that receives as parameter in the information window (Infolog) and
gives back the false value. Therefore, by means of the use of this method, we
obtained simultaneously both objective.
Example of use of CheckFailed
Boolean checkSomething ()
{
Boolean ret;
if (! something)
{
ret = checkFailed (`Something is wrong');
}
return ret;
}
We could use the previous structure, but cases exist in which it interests to
us to verify the same Something condition, present in
the CheckSomething method (), without
presenting/displaying no message to the user. In this case we would need an
additional method, that verified the condition but that it did not show any
message.
Nevertheless, this would not be very efficient, because we would be duplicating
the verification code, therefore is more recommendable to create a called method Something
(), to which we will be able to call when we want, that it will be in
charge to make this verification.
We will have, in addition, to change the CheckSomething method (),
so that it makes a call to this new method. The CheckSomething method () we
will use it solely when we want to show a message the user.
Example of complete validation
Boolean something ()
{
if (! something)
{
return false;
}
return true;
}
Boolean checkSomething ()
{
Boolean ret;
if (! something ())
{
ret = checkFailed (`Something is wrong');
}
return ret;
}
We can consider a standard of
nomenclature of Axapta, the use of the Check area code, in the name of all
those methods that make a call to the global method CheckFailed (). Of this
form we will know what methods present/display messages in the Infolog window.
