Settings can have multiple values, although this is not often used and
the UI has places where this is not properly honored. Fix the case
where we look for and prune uninitialized/immutable settings and
be sure to iterate over all the values to avoid a crash.
Fixes#11549
This attempts to warn Windows users who have had their devices
poisoned by the Prolific driver heist of the problem and the
workaround. Hopefully this will prevent users from opening bugs
thinking that CHIRP is at fault.
Related to #11552
This makes the UI consider the radio's tuning steps, if defined as
the first course of action. The existing code tried the standard
set followed by the radio's set, assuming the radio's would be a
subset, which is of course not always true.
This also makes required_step() consider the radio-specific steps
after the standard ones, if there are any strange ones to allow the
radio to define ones that are not in the standard list.
Related to #10968
The ft1d driver has seemingly had incorrect tuning step handling since
the beginning. As a result, stricter handling of tuning steps
provided by the radio started to break down. This fixes them to work
according to the OEM software for all the available steps.
This is the first pass at converting all drivers to use current_index
instead of current (value) when defining RadioSettingValueList items.
These are just the easy/straightforward cases where we have a list and
and index into that list. Other instances with more complex invocations
will be handled separately.
The files that ended up with long lines as a result of this were
autopep8'd with just long-line fixes applied.
Jamming a hundred errors into a MessageBox is not scalable and looks
pretty dumb after a few. This makes it into a proper dialog that
shows the first line of each and lets the user select each for better
readability.
Related to #11519
In order to help make more sense of why a CSV file isn't open-able,
we should log any headers we don't recognize so the user will see
them. Note that the test csv file in tests/images is from a billion
years ago, when we apparently had bank info as a column. With this,
the test that asserts we load CSV files with no errors fails on our
own sample file (!).
Related to #11519
If we fail to find a matching driver and the file appears to be a
".csv" file, return GenericCSV as a match. This will make us try to
open the file with the generic driver and thus capture loading error
messages and show them to the user. Otherwise we would just fail to
match a driver, and report the format is unsupported, which is
confusing to a user.
Related to #11519
Some software that spits out CSV may just quote everything, even when
not needed. Doing that prevents us from recognizing the header and
thus makes us think a file isn't in a known format.
Fixes: #11519
Memories that chirp edits from scratch ended up with more unknown
bits set, which interfered with the enabling of tones. This makes us
clear the memory to zero first (which appears to be the way other
software does it) and also set one of the unknown bits to a known
value.
Fixes#11451
The memory editor will fail with a 'KeyError: N' error if the user
attempts to paste more memories than will fit. This makes us not
choke, stop when we get to the end, and report to the user (unless
the memories that don't fit are empty).
Fixes#11510
This test has been wrong for a long time, basically never properly
asserting DTCS values for drivers. The three drivers fixed immediately
before this commit should have been caught by this test, but were not
because it was always skipping the dtcs field.
Related to #11506
This driver has been broken forever in how it handles DTCS tone mode.
It was always using the rx_dtcs field, which should only be honored
in a ->DTCS cross mode. The new GUI, being in hide-unused-fields mode
always made this clear, as it appeared to be snapping back to 023
always when the user selected a different value.
Note that the test is *also* broken, which I will fix at the end of
this series.
Related to #11506
This driver has been broken forever in how it handles DTCS tone mode.
It was always using the rx_dtcs field, which should only be honored
in a ->DTCS cross mode. The new GUI, being in hide-unused-fields mode
always made this clear, as it appeared to be snapping back to 023
always when the user selected a different value.
Note that the test is *also* broken, which I will fix at the end of
this series.
Related to #11506
This driver has been broken forever in how it handles DTCS tone mode.
It was always using the rx_dtcs field, which should only be honored
in a ->DTCS cross mode. The new GUI, being in hide-unused-fields mode
always made this clear, as it appeared to be snapping back to 023
always when the user selected a different value.
Note that the test is *also* broken, which I will fix at the end of
this series.
Fixes: #11506
