Protect field after passing over

[P Sam]

Dear All,

Please I need assistance in this scenario. In the data entry mode (demode()= add), after passing over a field (for instance FIELD_1), FIELD_1 will be automatically protected even after going back to FIELD_1 from FIELD_2. This implies that after providing response for a field (say FIELD_1), FIELD_1 will be automatically protected even after moving to the next field (FIELD_2) and going back to FIELD_1 while in the add mode. The essence of this scenario is to disallow the opportunity to modify a response, once an attempt has been made hence blocking the field.

[htuser]

It is possible to implement this using https://www.csprousers.org/help/cspro/s ... ction.html, --Field Properties--Protected--Yes.
However, you will have to think about data entry flow. For example, when you are back to an already entered field, the postproc statements are not executed and only the killfocus statements are executed (https://www.csprousers.org/help/cspro/k ... ement.html).

Hope this help.

[P Sam]

Thank you very much @htuser for your help. It works as suggested. The only challenge is that I want enumerators to confirm the response entered before they proceed to the next field. As it stands, in their confirmation if they indicate No as indicated in the postproc logic, it takes them to the previous question with no protection. I want to allow for confirmation and once it is confirmed (Yes) it will be protected but if No, enumerator can make amendment. The logic is provided below

Code: Select all

PROC S2_1_1
preproc
if demode()= 2 then
protect(S2_1_1, true)
endif;

killfocus
if demode() in 1 then
 if visualvalue($) in 0,1,2,3,998,999 then
 setproperty($, "Protected",true)
else
  setproperty($, "Protected",false)
  endif;
endif;


postproc
if demode()= 1 then
if visualvalue($)<> notappl then
errmsg("Enumerator: Are you sure students response to S2.1.1 is %s", getlabel(S2_1_1_VS1, S2_1_1))
select("Yes", continue, "No", S2_1_1);
endif;
endif;
savepartial();

[sherrell]

Are you protecting every single field as you exit it? For I've never heard of anyone doing this, it's very unconventional. Most enumerators just want to finish the case as soon as possible, so going back and changing responses has never been an issue. Are you seeing this? If so, when?

Also, do you have consistency messages in your application? For what happens if you have a test of two fields, the one they're on and a previously-keyed field. In your scenario the enumerator could never go back to change the earlier response.

[P Sam]

Thank you Sherrel for your response. We are conducting a study on student literacy and numeracy. The protocol is that each student has a chance to attempt a test (within a stipulated time but the issue of the timing has been resolved with the assistance of @htuser and @Gregory). This implies that once they have responded to a test, there is no chance to go back to change it again. In view of this protocol, the intention is to disallow any further amendment once the response has been keyed. The confirmation is to control for enumerator errors in keying responses so that the right response provided by the student is actually confirmed before they proceed for it to be protected. Also, to avoid any bias of a second chance once the test is already attempted.

[*]Are you protecting every single field as you exit it?
Response: I am protecting only the fields for the test as I exit. The test is in one section. All other sections are not protected

[*]Also, do you have consistency messages in your application? For what happens if you have a test of two fields, the one they're on and a previously-keyed field. In your scenario the enumerator could never go back to change the earlier response
Response: The previously keyed field (which is also a test) will be protected once it has already been responded to and confirmed and proceeded to the next field (say the field they're on). In the current field, until they have keyed a response, confirmed and proceeded to the next field it will remain unprotected.