[chirp_devel] [PATCH] [tg_uv2p] Inhibit keypad lock when in dual watch or crossmode. Fixes forth issue in #9939

[Ran Katz]

Hi Dan,

And again, thanks,
Indeed the exception is a good way to get the user's attention,
I submitted a new patch, using exceptions and checking the actual settings
value (not based on order).

Ran

On Fri, Aug 12, 2022 at 5:34 PM Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

> > Ideally I would like to reject it at the user (UI) level - is it
> possible to have co-dependent setting values, i.e. keypad lock has 2
> possible values ("locked", "unlocked") if rx_mode is "normal" (not DW) and
> only "unlocked" if rx mode is not "normal", and similarly  for rx_mode
> ("normal", "cross mode" and "DualWatch"  when keypad is unlocked and
> only"normal" when teh keypad is locked)?
>
> Well, like I say, if you're setting the dual-watch setting to on, you can
> raise an exception. So, if that setting is being set on, quickly check the
> keypad lock thing and raise if it's on. Same for the other - don't let the
> keypad lock be set if dual-watch is enabled. That has the same effect as
> tying them together in the UI, right?
>
> If I'm misremembering how well that would work, then I'd say we just need
> to not obsess over that level of detail. Keeping the UI driver-independent
> is important and, of course, not all things can be represented in an
> abstraction.
>
> --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/20220814/be1c9eeb/attachment-0001.html