Why Use IsChecked Instead of Pos


CSPro 7.4 has a new function ischecked. This function returns whether a code is part of a check box field’s selections. Prior to CSPro 7.4 we would use the pos function. So why use the ischecked function rather than the pos function?

Issue with Pos

Let’s look at how the LANGUAGE_SPOKEN variable would be set up. Since a person could speak multiple languages we will use a check box and the language question might look like:

alt text

Here English, French, Russian, and Spanish are checked. In previous versions of CSPro we would use the pos function to see if a specific language was checked. For example, if we wanted to know if French was checked we would use:

if pos("21", LANGUAGE_SPOKEN) then
    errmsg
("French is checked");
else
    errmsg
("French is not checked");
endif;

The error message “French is checked” would be issued. Continuing with our example we could ask if Russian is checked:

if pos("23", LANGUAGE_SPOKEN) then
    errmsg
("Russian is checked");
else
    errmsg
("Russian is not checked");
endif;

In this case pos would return a 1 (true) since Russian is checked and the error message “Russian is checked” would be issued.

If we asked if Hindi is checked:

if pos("33", LANGUAGE_SPOKEN) then
    errmsg
("Hindi is checked");
else
    errmsg
("Hindi is not checked");
endif;

The pos function would return a 0 (false) and the message “Hindi is not checked” would be issued.

Now let’s test if Bengali is checked:

if pos("32", LANGUAGE_SPOKEN) then
    errmsg
("Bengali is checked");
else
    errmsg
("Bengali is not checked");
endif;

The pos would return a 6 (true) and the message “Bengali is checked” would be issued.

But Bengali is not checked. What happened? The pos (“32”, LANGUAGE_SPOKEN) searched the string “11212324” found “32” in positions 6-7 returning a 6.

Explanation

The check box codes are placed at uniformly spaced offsets based on the size of the code. For example, if the check box field has a length of 20 and each code has a length of 2, then each selected code is placed in the respective 2-digit offset. That is, positions 1-2 for the 1st code, position 3-4 for the next code, and so on.

alt text

The data are stored in the file as shown here:

alt text

The pos function does not look by offset, but instead looks for a substring match. Unfortunately, the substring “32” does exist in the data and a false match is found. In previous versions of CSPro we would need to loop through the string being searched by 2 for the language code:

numeric languageFound = 0;

do varying numeric idx = 1 while idx <= length(LANGUAGE_SPOKEN) by 2
   
if LANGUAGE_SPOKEN[idx:2] = "32" then
       
languageFound = 1;
       
break;
   
endif;
enddo;

if languageFound then
    errmsg
("Bengali is checked");
else
    errmsg
("Bengali is not checked");
endif;

Moving Forward with IsChecked

CSPro 7.4 greatly simplifies this check with the ischecked function. The ischecked function checks for the codes at the appropriate offsets, in this case the function checks positions 1-2, 3-4, 5-6, 7-8, …, 19-29 for the code “32”. To check for Bengali we simply use:

if ischecked("32", LANGUAGE_SPOKEN) then
    errmsg
("Bengali is checked");
else
    errmsg
("Bengali is not checked");
endif;

The ischecked function returns a 0 (false) since “32” is not found within one of the uniformly spaced offsets. To do this CSPro requires the codes to be a uniform length. Notice all codes in this example were length 2.


#Logic