We are having trouble with a single interviewer (we many many), who is entering something weird at the end of an alphanumeric variable (the person´s name), resulting in a CRLF (\n), which in turn provokes an end of the record, and the next field will be positioned as being a new record, and CsPro treats it as another record with a bad record type (it is coming as a blank space).
He (the interviewer) says that he does nothing wrong, just hits the enter key to finish the field
We have already changed his table hoping it would solve the problem, but...
It is happening with a single operator, and the solution we have is to copy his csdb file, use a sqlite program to extract the data, and in a text editor, look for the extra \n and delete it. A pain.
Have you ever heard of something like that?
How can an operator enter a \n at the end of a field?
bad record type
-
Gregory Martin
- Posts: 1789
- Joined: December 5th, 2011, 11:27 pm
- Location: Washington, DC
Re: bad record type
What version of CSPro are you using? I thought that at one point we fixed a problem with line breaks being added to text, escaping it to \n, but I'm not sure if my memory is right on this.
This is Android, right?
This is Android, right?
Re: bad record type
I´m using version 7.3 with Android.
I´m not sure if it is always the case, but this problem occurs when there is two consecutive alpha fields, and the \n "appears" in the first one.
Is it possible that the interviewer enters a \n on purpose? Or something other then the \n that fakes an end of line in the field?
And if so, what would happen?
I was thinking around that situation a lot, and I´ll do some testing.
Maybe writing a small function to get rid of the \n if it exists might solve the problem.
What you think?
I´m not sure if it is always the case, but this problem occurs when there is two consecutive alpha fields, and the \n "appears" in the first one.
Is it possible that the interviewer enters a \n on purpose? Or something other then the \n that fakes an end of line in the field?
And if so, what would happen?
I was thinking around that situation a lot, and I´ll do some testing.
Maybe writing a small function to get rid of the \n if it exists might solve the problem.
What you think?
Best
Ari
Ari
-
btri Arjun
- Posts: 37
- Joined: August 17th, 2018, 6:09 am
Re: bad record type
Some days ago, I have also faced the very similar problems in some tablets. I was change the dictionary during the field and update the .pen file not .DCT. In this condition, I removed both .pen and .Dict file and upload new. Now those tablets are working well. Have you changed the dictionary during field? Which may be the cause.
Re: bad record type
I'm not sure what the interviewer is doing to create the "\n." I'm curious if they can reliably reproduce the issue by re-keying the problematic field? I'm sure we could fix it, if we could reproduce the issue.
Re: bad record type
We did not change the dictionary at all.
We´ve asked the interviewer if he was doing anything weird, and he said "of course not" (what would you expect?).
We are trying to eliminate all the possible causes, like walking in the tree, etc, to see if it does not happen again.
We´ve asked the interviewer if he was doing anything weird, and he said "of course not" (what would you expect?).
We are trying to eliminate all the possible causes, like walking in the tree, etc, to see if it does not happen again.
Best
Ari
Ari
Re: bad record type
I think I´ve found the problem:
After some testing (and talking to one or two interviewers), the bad record type is provoked by a end of record (\n) generated when the interviewer uses the smart typing and the predictive text (when the machine try to guess what the person wants to say).
When using that and accepting the words that the machine displayed, in some cases, I could not pinpoint exactly how it is done, the field (the person´s name) is filled with the automatic text AND the \n at the end, generating the bad record type.
After some testing (and talking to one or two interviewers), the bad record type is provoked by a end of record (\n) generated when the interviewer uses the smart typing and the predictive text (when the machine try to guess what the person wants to say).
When using that and accepting the words that the machine displayed, in some cases, I could not pinpoint exactly how it is done, the field (the person´s name) is filled with the automatic text AND the \n at the end, generating the bad record type.
Best
Ari
Ari
Re: bad record type
Thanks for that information. That could be a useful clue. I have a theory about this. On your form for the text boxes are you using the "Text Box (multiline)" capture type? That is not the default setting so most likely you are not unless you specifically changed the capture type after dropping the items on the form. If you are using the default single line text capture type then I think this could be an unfortunate interaction of the text suggestion somehow adding newlines into what is supposed to be a single line text field and CSPro trusting that Android is not giving text with newlines when we tell it to use a single line text box.
In CSEntry there are two types of text fields, single line and multi-line, based on the capture type set in field properties. When we create the edit box for a text control on Android we look at the capture type and if it is single line we tell Android to use an edit box that permits only a single line of text. According to the Android documentation this text box setting should never allow more than one line of text so there should be no newlines in the resulting text. The code that processes the text that is output from this edit box trusts that it will not have any newlines in it so it just writes the raw text to the data file. However, if the edit box is multiline we assume it may contain newlines and we escape the newline characters before writing to the data file to avoid issues like what you are facing. So my theory is that you are using single line text boxes and somehow the auto-suggest is able to introduce newlines in an editbox that should not have them.
We can easily change the behavior of CSEntry to always escape newline characters even in single line text. Basically treat all text from Android as if it was multiline. If my theory is correct you will no longer have problems with invalid record types. We will make you a build with this fix that you can have your interviewer test out to see if it fixes the problem. You will still have newlines in your data which may cause you problems later on in your processing but you can fix them in batch later on if needed.
Is the interviewer that is having this issue using a different software keyboard? I ask because there are a lot of third party keyboard apps that replace the default software keyboard and if your interviewer is using one of them it could be incorrectly adding the newlines. One of my tablets came with a couple of different keyboard apps installed that you can choose from that all behave differently.
You could also try clearing the auto suggest history in case it just has some bad data in it. Here is a link that describes how: https://android.stackexchange.com/quest ... uggestions
In CSEntry there are two types of text fields, single line and multi-line, based on the capture type set in field properties. When we create the edit box for a text control on Android we look at the capture type and if it is single line we tell Android to use an edit box that permits only a single line of text. According to the Android documentation this text box setting should never allow more than one line of text so there should be no newlines in the resulting text. The code that processes the text that is output from this edit box trusts that it will not have any newlines in it so it just writes the raw text to the data file. However, if the edit box is multiline we assume it may contain newlines and we escape the newline characters before writing to the data file to avoid issues like what you are facing. So my theory is that you are using single line text boxes and somehow the auto-suggest is able to introduce newlines in an editbox that should not have them.
We can easily change the behavior of CSEntry to always escape newline characters even in single line text. Basically treat all text from Android as if it was multiline. If my theory is correct you will no longer have problems with invalid record types. We will make you a build with this fix that you can have your interviewer test out to see if it fixes the problem. You will still have newlines in your data which may cause you problems later on in your processing but you can fix them in batch later on if needed.
Is the interviewer that is having this issue using a different software keyboard? I ask because there are a lot of third party keyboard apps that replace the default software keyboard and if your interviewer is using one of them it could be incorrectly adding the newlines. One of my tablets came with a couple of different keyboard apps installed that you can choose from that all behave differently.
You could also try clearing the auto suggest history in case it just has some bad data in it. Here is a link that describes how: https://android.stackexchange.com/quest ... uggestions
Re: bad record type
Thank you for your note.
As for the field type, we always use the single line text box (I´ve already checked that before reporting the problem). The difference you all our applications is that we use the text box WITH the tickmarks, because it shows exactly the field length, whereas the text box without ticks show a "clear" space much shorter than the actual field length.
As for the keyboard, I cannot guarantee that this particular interviewer is not using a third party (he said he did not touch that facility, but...), but the testing I´ve done on my Samsung with the standard keyboard provoked the same error.
We´ve triggered a note for all the interviewers which are presently in the field not to use this automatic facility.
For the new interviewers we are giving tablets where we disconnected this automatic text facility, and for the next applications we intend to check the existence of the \n in the killfocus.
I´ll keep trying to make more tests to see if I can detect precisely where and when the problem occurs.
As for the field type, we always use the single line text box (I´ve already checked that before reporting the problem). The difference you all our applications is that we use the text box WITH the tickmarks, because it shows exactly the field length, whereas the text box without ticks show a "clear" space much shorter than the actual field length.
As for the keyboard, I cannot guarantee that this particular interviewer is not using a third party (he said he did not touch that facility, but...), but the testing I´ve done on my Samsung with the standard keyboard provoked the same error.
We´ve triggered a note for all the interviewers which are presently in the field not to use this automatic facility.
For the new interviewers we are giving tablets where we disconnected this automatic text facility, and for the next applications we intend to check the existence of the \n in the killfocus.
I´ll keep trying to make more tests to see if I can detect precisely where and when the problem occurs.
Best
Ari
Ari