<div dir="ltr"><div dir="ltr">Hi Dan, <div>Thanks again,</div><div><br></div><div>I will submit a patch shortly (running tests now) with the added &quot;change&quot; logic you proposed.</div><div>I also removed the explicit &quot;good&quot; setting from both settings - as the radio is not really broken - it is functional but is locked in the not normal) mode you are in and cannot be unlocked from the keypad - only from chirp, so if the user has such a setting , maybe  it is intentional? furthermore it will keep the UI sync&#39;d with the actual setting. </div><div><br></div><div>Is there a way to raise an &quot;informative&quot; message ? (not an exception that will abort the set_settings loop) so that the user can be notified he has a &quot;special&quot; configuration?</div><div><br></div><div>Ran</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 21, 2022 at 6:13 PM Dan Smith via chirp_devel &lt;<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&gt;                     elif setting == &quot;keyunlocked&quot;:<br>
&gt; -                        LOG.debug(&quot;Setting %s = %s&quot; % (setting, not int(element.value)))<br>
&gt; +                        if int(element.value):<br>
&gt; +                            if (getattr(obj, &quot;rxmode&quot;) != 0x02):<br>
&gt; +                                LOG.debug(&quot;Setting %s = %s&quot; % (setting, True))<br>
&gt; +                                setattr(obj, setting, True)<br>
&gt; +                                raise errors.InvalidValueError(<br>
&gt; +                                    &quot;Keypad lock not allowed in &quot;<br>
&gt; +                                    &quot;Dual-Watch or CrossMode&quot;)<br>
&gt; +                        LOG.debug(&quot;Setting %s = %s&quot; % (setting,<br>
&gt; +                                                       not int(element.value)))<br>
&gt;                         setattr(obj, setting, not int(element.value))<br>
<br>
Since you&#39;re always raising, I think this is likely to be confusing because it&#39;s going to raise an exception to people who haven&#39;t changed that setting, and abort making the actual change they want, right?<br>
<br>
Meaning, let&#39;s say I have a radio with the settings already set to the incompatible state (i.e. in dual-watch and keylock enabled). I open up the settings to make a change to something completely different like the backlight timer or something. When I do that, the UI is going to try to set all the settings, including the two incompatible ones that I didn&#39;t touch. I&#39;ll get an error and then potentially my backlight setting won&#39;t be changed if it is later in the list than the keylock one above (since the exception will abort our loop).<br>
<br>
So I think you need some additional logic to check both stored values before you raise to avoid this breakage, Something like:<br>
<br>
if setting_keylock:<br>
    if is_dualwatch and now is_keylocked and setting_keylock.value == locked:<br>
        raise Error<br>
<br>
So basically, only raise the exception if they&#39;re changing keylock (or dual watch) to a bad combination. It looks like you&#39;re also asserting the keylock off before you raise, which would fix an existing broken radio, right? That probably makes sense to include in there regardless, but I think you should remove the explicit setting from this section:<br>
<br>
<br>
&gt; +                    elif setting == &quot;rxmode&quot;:<br>
&gt; +                        if int(element.value) != 2:<br>
&gt; +                            if not (getattr(obj, &quot;keyunlocked&quot;)):<br>
&gt; +                                LOG.debug(&quot;Setting %s = %s&quot; % (setting,<br>
&gt; +                                                               &quot;Normal&quot;))<br>
&gt; +                                setattr(obj, setting, 0x02)<br>
&gt; +                                raise errors.InvalidValueError(<br>
&gt; +                                    &quot;Dual-Watch or CrossMode can not be set &quot;<br>
&gt; +                                    &quot;when keypad is locked&quot;)<br>
&gt; +                        LOG.debug(&quot;Setting %s = %s&quot; % (setting, element.value))<br>
&gt; +                        setattr(obj, setting, element.value)<br>
<br>
I was going to say that this will &quot;fight&quot; the other one and end up with both values changed in a radio with those flags conflicting in memory. However, it won&#39;t - only the first one to be encountered will do that, but which one will get flipped is not deterministic. I think flipping off the keylock is the better &quot;fix the problem for them&quot; approach.<br>
<br>
--Dan<br>
<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div></div>