Consultor Eletrônico

Not recommended using blanks in a FORMAT of a LOGICAL field

Using a FORMAT containing blanks in a LOGICAL field may have some not
desirable side efects which might be confused with bugs.

Let's take this code as example:

DEF VAR a AS LOGICAL FORMAT "YES/ " INIT TRUE.
UPDATE a.

If you enter a blank space in the field, Progress will generate the
following errors:

** Input value: should be YES/ . (87)
Unable to evaluate field for assignment. (143)

Progress is not matching the space in the format with the space you
type in the fill-in. This happens because Progress removes trailing
spaces from input in fill-ins, so the space you type is lost. Then
when Progress compares what you typed to what it expects from the
format, the two don't compare and error 87 is displayed.

You can remove the space from the format, for example:

DEF VAR a AS LOGICAL FORMAT "YES/" INIT TRUE.
UPDATE a.

but then it is more difficult for the user to clear the value: He has
to press F8 on Unix; on Windows the CLEAR function has no default and
has to be defined in the program, for example:

ON F8 CLEAR.
DEF VAR a AS LOGICAL FORMAT "YES/" INIT TRUE.
UPDATE a.

Another option for Windows (and also Unix) environments would be using
TOGGLE-BOXes, for example:

DEF VAR a AS LOGICAL INIT TRUE.
UPDATE a VIEW-AS TOGGLE-BOX.

But in any case it is advisable to avoid the use of blank spaces in
the FORMAT of LOGICAL fields.


jsa
19 Jan 98


Progress Software Technical Support Note # 17580