[chirp_users] New Daily Build

Build System donotreply at danplanet.com
Thu Mar 30 00:07:09 PDT 2017


A new daily build of CHIRP is available.  This includes changes made
directly to the tree yesterday, and may include additional features,
bug fixes, and/or bugs.  If you are interested in trying it, grab it
from the following location:


A list of the changes included in this build (since the last daily)

Changes for Build #473
[Tom Hayward <tom at tomh.us>] Fix edge test so high bound is within valid_bands. #4689

[SASANO Takayoshi <uaa at mx5.nisiq.net>] patch for bug#4687, discard echoback immediately to avoid
OS's serial RX buffer overflow.

[Tom Hayward <tom at tomh.us>] Natively support null-terminated strings in Browser. #4685

When a bitwise char array that contains a null character is requested 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__
  File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 206, in _build_ui
TypeError: Gtk.Entry.set_text() argument 1 must be string without null bytes, not str

This error 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 the browser should be
able to display it.

This change 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.

More information about the chirp_users mailing list