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@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers