There are three methods that limit users as to what can be entered in an entry field. The first two methods work character by character while the third responds to the entry field when the cursor moves out of it. Note that clicking on dialog frame objects (the title bar, scroll bars, system menu, etc.), other regions, or other applications does not trigger the 'on validation' response.

1.You can use a mask format (see entry field - mask in the Reference Guide) with the { } place holder. For example, if only the letters 'a' through 'f' were to be allowed, the following mask could be set up:

This mask is only for the first character entered in the entry field. Duplicate the { } setup for each character to be masked. This is limited to 255 characters and cannot be specified using a variable.

Masks are specified as part of the entry field definition and their values are compiled into the binary WEB file. This means that if you want to dynamically change a mask, you should dynamically delete and then dynamically add an entry field with the desired mask.

Masks are generally in the form of uppercase characters, one for each allowable character that can be typed into the field (see entry field - mask in the Reference Guide). For example, a mask of 'UUULLI' would force the first three characters in the entry field to be uppercase, the second two characters to be lower case, and the last character to be an integer. Using this mask does not require all 6 characters to be typed into the field. No characters have to be typed into the field unless the field has been defined with the 'required' attribute (see entry field - required in the Reference Guide).

2.If a response to the entry field is coded (without any on clauses), that response is generated each time the user types a character. You can then work with the text of the entry field. For example, you could change the text to the value returned from the ToUpper function in ESLSTR. (This is a commonly used procedure for when you need to allow spaces, but the U specification of a mask does not allow spaces.) Whilst this approach is simple, there is an issue when attempting to insert characters into the middle of the string within the entry field. The process of writing the string to the entry field moves the input cursor to the end of the string which can be very annoying for the operator. Without resorting to 'C' DLL, it is impossible to pick-up the current cursor in an entry field, therefore a more reliable approach is to perform the ToUpper function within the validation event, as in the next method.

3.The last method involves coding a response to the entry field on validation (see response to OBJECT - on validation in the Reference Guide). You then manually code the validation using a combination of extraction, built-in functions, conditional clauses, etc. This enables more complex validation to be implemented, and adds functionality not available with simple masks.

For example, say we want the entry field to make sure that there is always at least and no more than 6 characters, you could code something like the following.

If the length was not 6 characters, you could bring up a ReplyToMessage box to warn the user of this condition or you could simply activate the entry field again until 6 characters are entered. You should beware that activating an entry field may trigger a validation response to another entry field. If multiple entry fields within a dialog use the validation response to activate themselves when invalid then a 'deadly embrace' can occur which will result in the ESL application looping.