Android Question barcode scanner into EditText - CRLF not detected

just to clarify, CRLF means different things to different people. for my barcode scanner, CRLF is chr(13) + chr(10). for B4X, CRLF is chr(10).
if i want my barcode scanner to append chr(10) only, i can tell it to do that. i can also tell it not to append any characters. the so-called ENTER key is chr(13).
perhaps your scanner is appending chr(13)... this might account for why you do not find chr(10) at the end.

My barcode scanner is appending Chr(13) and Chr(10) to the data - a normal Enter keystroke. I can detect neither in the TextChanged sub. If I set the scanner to append a tab keystroke - Chr(9) - this single character cannot be detected either. I can use my own suffix, such as "####" and it works fine. The problem is detecting non-viewable ascii characters.

it doesn't work in textchanged. if you look at the hex values of the result after edittext has been populated, you'll see either 0D or 0A. at least, i do.

I do not know how to see the hex values of the edit text - how do you do this? And, you confirmed that the non-viewable ascii characters are not sent to the TextChanged sub?

those characters are, by definition, non-printing characters. they serve other purposes,
but they are certainly part of the byte stream. and you don't need me to tell you what
you already see: textchanged may or may not behave as you expect.

the os interprets these low ascii values as control characters. chr(10) might involve
moving a cursor to a new line (of text). it might involve unsetting the view's focus. it
might be part of a stream of bytes, which when placed in the context of "lines of text"
causes a linefeed in between each "line". but, in such a context, the lines would not
include the chr(10). in common usage, a string of text doesn't end with chr(10).
end of input, however, may be signalled by chr(10) which is not going to be included
in the string. and a string of bytes can terminate with chr(10) (but if you look at those
bytes in a text context, the chr(10) will be dealt with as the os determines in that
context.

gets you your bytes.

agraham's byteconverter library will allow you to print those values as a hex string:

technically, UTF8 should work, but things depend on the symbology your scanner is looking at.

by the way, once you have determined that the barcode actually ends with chr(10), then you just drop it. you don't have to go through all the stuff you had:
dim fixedbarcode as string = originalbarcode.substring2(0,originalbarcode.length - 1)

also if define a string as "12345" & crlf, its length is 6, even though you can't see the crlf. but you can remove it. depending on the contect in which you place this string, it may have already been seen and dealt with by the os.

May be you can use a <textarea> field to receive the scan data with crlf, or try multiple lines edittext field.