Big Bug ! App Inventor is deleting part of the code after closing and reopening the project

text box and text field are the same. :wink: App Inventors official name is "string block".

Delete first char y try again


Good eyes. :grin:

Just tested it. The character/escape code thingy is preventing the text box from being copied to the backpack.

Dear Peter,


Anyway I created text box to be sure.

Then I removed the special character from the beggin.

After that i tryed to save and close.

After reopening that, it works.
I tryed aso to export aia and re import.

It works also!!!

The character was part of the zpl label. Anyway after deleting it it is still working.

Thank you very much for your time and great support !!!

1 Like

@Juan_Antonio found the solution. Still like to know what "character" caused the problem. This is something that shouldn't happen.

ascii 197 = ┼

ascii197hereCT~~CD,~CC^~CT~ ^XA ~TA000 ~

1 Like


Perhaps is this

ascii 16 = DLE


but when i unzip the .aia i get this


I tested DLE and that wasn't it.

But I also think it should be one of the C0 controls.

It's 16 = DLE, but when you copy paste
" Click to copy and paste symbol" is converted to: 238 128 144

1 Like

Again good catch.



The data link escape character (DLE) was intended to be a signal to the other end of a data link that the following character is a control character such as STX or ETX.

Furthermore, what is data link escape? data link escape - Computer Definition A communications control character that indicates that the following character is not data, but a control code.

It's a Byte Order Mark isn't it?

Had to search that also :grin:

The byte order mark (BOM ) is a particular usage of the special Unicode character, U+FEFF BYTE ORDER MARK, whose appearance as a magic number at the start of a text stream can signal several things to a program reading the text:[1]

@David_S 's app is interesting because it manages to send control characters to a Zebra Bluetooth printer.

1 Like

(added to FAQ)

(added to FAQ)

This is a known issue, and is due to the fact that while browsers will gladly emit XML that contains certain unallowed characters, they will refuse to parse that XML on the way back in. We do have a potential workaround in the pipeline and I'll see what we can do about getting that into the next release.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.