The problem reproduced in 0.5.0.

Regarding "Does not have latest standalone version to test there."
Do you want a standalone version?

For now 0.4.0 is sufficient. The enhancements in 0.5.0 sound useful, but I'm OK
without them also :)

The problem that 00 in UTF-8 is treated as end of string. When "41 41 00 41 41" is
converted to text, it actually creates string "AA[end of string]AA", so length()
returns 2. 
So Text.getText() returns "AA".

This kinda curious case. The encoder cannot support text that cannon be encoded
properly. So the steps 1-3 are correct.

The question is regarding step 4.
It may be useful to keep the byte[] reference if the user clicks "show bytes" again.
But what happens if the user changes the text? Should the byte[] be dumped?

Thoughts?

I think step 3 should give some indication about what happens there. In my case I
pasted pretty long byte array (that occasionally had 00 byte somewhere close to the
beginning), converted it to text (unchecked the box) and was surprised to see
something very short as a result.

Maybe you can always use byte[] to store actual data and convert to String for
display only?

Not that simple. Let's say you paste "41 41 00 41 41" into the bytes view and uncheck
the box.
The state is the following:
byte[]=41 41 00 41 41
text="AA"
Let's say you decide to append "B" to text, what should happen? I cannot sync "AAB"
to "41 41 00 41 41" since it will cause "41 41 42"

I think that maximum I can do is adding a warning message if the result of
"byte[]<->String" transformation is not commutative.

So, the problematic moment is 'byte => string' display change, since the user may
loose data here. At this point you may check something like 'bytes ==
bytes=>string=>bytes'. Probably the confirmation message ("The conversion is not
reversible. Do you want to continue?") at this stage is the best solution.

Yep, I'll do something like this. May be I'll even provide an additional info...

Let's target it for 0.5.1
I'll also try to make a standalone version for this one.

Thanks!

(No comment was entered for this change.)