[chirp_devel] Inverted Boolean Help Needed
The UV-B5/B6 has a ON/OFF setting that is inverted. 0 = ON and 1 = OFF.
I was using a list to get around it. Then I saw in the h777.py driver there were a pair of inverted settings. It thought I replicated this for my needs but apparently I didn't do enough testing and what I have is broken. This is in the uvb5.py driver.
Here is the setting...
rs = RadioSetting("beep_tone", "Beep Prompt", RadioSettingValueBoolean(not _settings.beep_tone)) basic.append(rs)
And here is the rest...
if element.has_apply_callback(): print "Using apply callback" element.run_apply_callback() elif setting == "beep_tone": print "Setting %s = %s" % (setting, not (element.value)) setattr(obj, setting, not (element.value)) else: print "Setting %s = %s" % (setting, element.value) setattr(obj, setting, element.value) except Exception, e: print element.get_name() raise
No matter if the setting is enabled or disabled, FALSE is always returned so the Beep Prompt is always enabled.
Can somebody spot what I am doing wrong?
Thanks, Jim
Not that this fixes your specific problem, but I have run into a few different settings which have this sort of "inverted" logic. To keep things simple in the rest of the code, I just name the setting appropriately so that the logic in the rest of the program need not be inverted, e.g., name your setting foo_disable if value of True/1 disables foo, and foo_enable if True/1 enables foo.
I think it makes it easier to read. "beep_tone" is a boolean? If I'm reading that "beep_tone_disabled" seems like it would be a much more meaningful name for the setting field.
________________________________ From: Jim Unroe rock.unroe@gmail.com To: chirp-devel chirp_devel@intrepid.danplanet.com Sent: Monday, January 20, 2014 8:53 PM Subject: [chirp_devel] Inverted Boolean Help Needed
The UV-B5/B6 has a ON/OFF setting that is inverted. 0 = ON and 1 = OFF.
I was using a list to get around it. Then I saw in the h777.py driver there were a pair of inverted settings. It thought I replicated this for my needs but apparently I didn't do enough testing and what I have is broken. This is in the uvb5.py driver.
Here is the setting...
rs = RadioSetting("beep_tone", "Beep Prompt", RadioSettingValueBoolean(not _settings.beep_tone)) basic.append(rs)
And here is the rest...
if element.has_apply_callback(): print "Using apply callback" element.run_apply_callback() elif setting == "beep_tone": print "Setting %s = %s" % (setting, not (element.value)) setattr(obj, setting, not (element.value)) else: print "Setting %s = %s" % (setting, element.value) setattr(obj, setting, element.value) except Exception, e: print element.get_name() raise
No matter if the setting is enabled or disabled, FALSE is always returned so the Beep Prompt is always enabled.
Can somebody spot what I am doing wrong?
Thanks, Jim
_______________________________________________ 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
On Mon, Jan 20, 2014 at 10:04 PM, Jens J. kd4tjx@yahoo.com wrote:
Not that this fixes your specific problem, but I have run into a few different settings which have this sort of "inverted" logic. To keep things simple in the rest of the code, I just name the setting appropriately so that the logic in the rest of the program need not be inverted, e.g., name your setting foo_disable if value of True/1 disables foo, and foo_enable if True/1 enables foo.
I think it makes it easier to read. "beep_tone" is a boolean? If I'm reading that "beep_tone_disabled" seems like it would be a much more meaningful name for the setting field.
Jens,
That makes sense. If I can figure out how to fix this, I can change that too.
Jim
Don't have the time to test myself but I would check in the direction of type conversion: check the type of the variable and eventually replace "NOT" with appropriate comparision (eg == 0)
my two cents 73 de IZ3GME Marco
On 21/01/2014 04:09, Jim Unroe wrote:
On Mon, Jan 20, 2014 at 10:04 PM, Jens J. <kd4tjx@yahoo.com mailto:kd4tjx@yahoo.com> wrote:
Not that this fixes your specific problem, but I have run into a few different settings which have this sort of "inverted" logic. To keep things simple in the rest of the code, I just name the setting appropriately so that the logic in the rest of the program need not be inverted, e.g., name your setting foo_disable if value of True/1 disables foo, and foo_enable if True/1 enables foo. I think it makes it easier to read. "beep_tone" is a boolean? If I'm reading that "beep_tone_disabled" seems like it would be a much more meaningful name for the setting field.Jens,
That makes sense. If I can figure out how to fix this, I can change that too.
Jim
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
participants (3)
-
IZ3GME Marco -
Jens J. -
Jim Unroe