# HG changeset patch # User Tom Hayward tom@tomh.us # Date 1490595310 25200 # Sun Mar 26 23:15:10 2017 -0700 # Node ID 50462c735ef1eee2d3bb2bb2c4d0f49fa0a4f2ef # Parent c558e223d37835907823f1804ade6a8bcf0b4594 [RFC] Natively support null-terminated strings in Browser.
When a bitwise char array that contains a null character is requsted in the Browser, there is an error:
Traceback (most recent call last): File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 313, in _tree_click e = CharArrayEditor(item) File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 123, in __init__ self._build_ui() File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 206, in _build_ui ent.set_text(str(self._element)) TypeError: Gtk.Entry.set_text() argument 1 must be string without null bytes, not str
This errors results in the char array contents not being displayed at all. All we get is the attribute name.
Radios commonly store strings shorter than the maximum length with null characters filling the remaining space. This is so common that I think the browser should be able to display it.
This patch strips the null characters off the char array so that Gtk doesn't freak out. This results in the string being displayed correctly.
The side effect is that the null characters are discarded on change. If the field is edited in the browser, Chirp fills the empty chars with spaces, not null characters like were there originally. Visually there is no difference, but the stored data are different.
I don't think this will break anything. Can anyone think of a reason this would be a problem?
Is this complete? Should \xFF be stripped as well? They're visually unpleasing, but don't break Gtk like \x00 does.
Seems okay to me. And yeah, if we're displaying as a string we should probably either filter out the obvious ones (0x00 and 0xFF) or maybe just filter for printable ascii.
--Dan