[chirp_devel] [PATCH] [tg_uv2p] Inhibit keypad lock when in dual watch or crossmode. Fixes forth issue in #9939
# HG changeset patch # User Ran Katz rankatz@gmail.com # Date 1659530381 -10800 # Wed Aug 03 15:39:41 2022 +0300 # Node ID 7c1a4c8b1c8dd4e97f2f31b89ed1e158adafb6d9 # Parent 5dbf582fbc464805b2e5322920f04d78a28a8947 [tg_uv2p] Inhibit keypad lock when in dual watch or crossmode. Fixes forth issue in #9939 This is a radio feature when using the keypad :keypad lock cannot be applied (or releaswed) when in the above modes, now chirp behaves similarly.
diff --git a/chirp/drivers/tg_uv2p.py b/chirp/drivers/tg_uv2p.py --- a/chirp/drivers/tg_uv2p.py +++ b/chirp/drivers/tg_uv2p.py @@ -212,6 +212,8 @@
_memsize = 0x2000
+ RxModeKeyUnLock_FLAG = False + @classmethod def get_prompts(cls): rp = chirp_common.RadioPrompts() @@ -496,7 +498,9 @@ cfg_grp.append(rs)
# Keypad lock - rs = RadioSetting("keyunlocked", "Keypad Lock", + rs = RadioSetting("keyunlocked", "Keypad Lock\n" + + "Note: will not be set (locked)\n" + + "if RX is in Dual/Cross mode", RadioSettingValueBoolean( not _settings.keyunlocked)) cfg_grp.append(rs) @@ -707,7 +711,21 @@ elif setting == "busy_lockout": setattr(obj, setting, not int(element.value)) elif setting == "keyunlocked": - setattr(obj, setting, not int(element.value)) + if self.RxModeKeyUnLock_FLAG: + val = True + else: + val = not int(element.value) + LOG.debug("Setting %s = %s" % (setting, val)) + setattr(obj, setting, val) + elif setting == "rxmode": + if int(element.value) < 2: + self.RxModeKeyUnLock_FLAG = True + LOG.debug("Due to RxMode not normal, " + + "forcing keylock to unlock") + else: + self.RxModeKeyUnLock_FLAG = False + LOG.debug("Setting %s = %s" % (setting, element.value)) + setattr(obj, setting, element.value) elif element.value.get_mutable(): LOG.debug("Setting %s = %s" % (setting, element.value)) setattr(obj, setting, element.value)
[tg_uv2p] Inhibit keypad lock when in dual watch or crossmode. Fixes forth issue in #9939 This is a radio feature when using the keypad :keypad lock cannot be applied (or releaswed) when in the above modes, now chirp behaves similarly.
Can you explain exactly what you're trying to accomplish here? It looks to me like you're depending on the order in which a bunch of settings are applied, and are stashing the value of one setting so the behavior of another one can be altered. That's fragile and won't work if the settings are reordered anywhere through the process. If you really need to do this, I think you should examine the state of the setting, either in the settings list or in the memobj.
I'm not sure what the radio behavior here is, but I think you're saying that when in dual-watch, the radio won't let you set the keylock enabled, is that right? If so, I think the better behavior is to reject the setting if it's invalid. So if keylock is enabled, refuse to allow setting DW. And if DW is enabled, refuse the allow setting keylock. Otherwise I suspect the UI is going to get out of sync with reality.
--Dan
participants (2)
-
Dan Smith -
Ran Katz