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@intrepid.danplanet.com> wrote:
> # HG changeset patch
> # User DanClemmensen <DanClemmensen@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@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers