[chirp_devel] [PATCH] [ft4] allow validation of RO frequencies [#6615]

[Dan Clemmensen]

Sorry about my tersness. The last thing you need at this point is to be
distracted from the py3 work.

I submitted the memedit.py patch as a standalone instead of part of my  RO
channel patch because I know you prefer simple standalone patches where
possible, and for good reason.

The problem is that I added TX Frequency validation to the validate_memory
method of my driver. After failing using other approaches, I went back to a
March 14 e-mail on the devel list where Jim Unroe pointed me at
gmrs_uv1.py. He extends the validate_memory method. I did the same for my
new code.  The problem is that that the mem structure passed to
validate_memory is not the same as the one later passed to mem_set:
Specifically, If the "duplex" field is "off" in the UI column, mem.duplex
is set to "" when it reaches validate_memory. If it is "split" in the UI
column, it gets changed in some other way that makes it different from
what is passed to set_memory.  I looked for and failed to find the spot
where the value is changed back to "off" or "split".

Without this change, My modifed driver rejects an RO channel (i.e., one
that has duplex "off") that has a frequency that is invalid for TX, and the
UI "duplex" column is forced back to "". With this change, my driver works.

I have not yet looked at the py3 branch, but I will after I get this patch
into the main branch.

How would you like me to provide the modified driver for your testing? Just
as a patch in the usual manner?  No new image is needed.

On Wed, Mar 27, 2019 at 6:53 AM Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

> > # HG changeset patch
> > # User DanClemmensen <DanClemmensen at gmail.com>
> > # Date 1553532256 25200
> > #      Mon Mar 25 09:44:16 2019 -0700
> > # Node ID 034168b01eceb10301f04dd8596c03aa1267099f
> > # Parent  936bffe5c76c85e7dd626c448b0e9031d274235c
> > [ft4] allow validation of RO frequencies [#6615]
> > Fixes: #6615
> > This change to the UI does not implement any RO changes. It
> > permits a river to implement such a change.
> >
> > diff -r 936bffe5c76c -r 034168b01ece chirp/ui/memedit.py
> > --- a/chirp/ui/memedit.py     Tue Mar 19 12:58:02 2019 -0700
> > +++ b/chirp/ui/memedit.py     Mon Mar 25 09:44:16 2019 -0700
> > @@ -137,6 +137,9 @@
> >         was_filled, prev = self.store.get(iter, self.col("_filled"),
> colnum)
> >
> >         def set_offset(offset):
> > +            old_dup = self.store.get(iter, self.col(_("Duplex")))[0]
> > +            if old_dup in ["off", "split"]:
> > +               return
> >             if offset > 0:
> >                 dup = "+"
> >             elif offset == 0:
>
> I'm confused about what you're trying to do here, and having basically no
> explanation in the commit message isn't helping. I've read the bug and the
> reason for re-opening it, but I'm not sure what behavior you're describing.
> If I use the UV-5R driver, I can set a memory to "off" and it stays that
> way.
>
> Can you please describe what you're fixing and why? If I have to use your
> driver and test image to reproduce, please put steps in the bug or
> something.
>
> --Dan
>
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20190327/629f202e/attachment-0001.html