Dan,
Here is what I have been working on. I've gone about as far as I can without some additional help.

I could not get the patch file that you sent to import. I found what look to be good instructions, but there were lots of errors reported (probably something I did). There wasn't that much that changed so I was easily able to add the changes manually. I used the settingsedit.py that you provided as-is. The only change I made to settings.py was to bump the precision setting of 'RadioSettingValueFloat(RadioSettingValue): from 4 to 5.

All of these settings determine the state that the UV-5R will be in when the Upload To Radio process is completed. So the CHIRP user can select:
- Channel of Frequency mode
- [A]/[B] display
- the selected channel for each display
- the VFO frequency (and BAND) for each display
and that is the way the UV-5R will be when the cloning process completes.

Except for the Channel/Frequency mode selection, it don't think the rest are available anywhere else.

Everything works except the VFO frequency settings. I was able to successfully pull the frequency from the UV-5R as individual bytes and change it to a floating point value to get it displayed. What I haven't figured out (and that is the main thing I need your help with) is getting the user's frequency changes back to the radio.

Entering the frequency works great. The proper error is returned for below 137 MHz, above 512 MHz (in need to get that changed to 520 MHz) and in between 174 MHz and 400 MHz.Thanks.

Seems to me that the band settings could be determined and set in the background by 'looking' at the frequency. If it starts with a 1 set it to VHF, if it starts with a 4 or 5 (or if it is not a 1) set it to UHF. That way the BAND settings could be removed. I do no that if you stuff in a VHF frequency in the UV-5R while the VFO is set to UHF, you get a weird result in the display.

A 'would be nice' thing would be to allow only programmed channels to be selected in the MR A/B Channel selecton. Unless it would be really easy to implement, I probably wouldn't mess with it since choosing an unprogrammed channel cause the UV-5R to select channel 0. Not much harm in that.

Thanks again for the 'float_setting_callback_example' patch. That really propelled me much farther that I thought I could get in in a couple of days.

Any advice, help and/or hints on the above will be greatly appreciated.

Thanks in advance,
Jim


On Thu, Jan 3, 2013 at 11:34 PM, Dan Smith <dsmith@danplanet.com> wrote:
Hi Jim,

> I want to use a section of code something like this. This already
> works, but is there a better way to do it? What it need to do is
> allow the user to see and edit a VHF or UHF frequency within the
> allowable frequency range. It would be nice if it could be displayed
> and edited similar to a cell in the spreadsheet view.

Okay, so what you're asking for is completely valid, but not really
something that is easy with the current settings architecture. However,
that's not a good excuse :)

I've attached a patch of some sloppy test code to get close, I think.
If this works for you, I can clean it up and make it suitable for
inclusion in the tree. It does the following:

1. It introduces a RadioSettingValueFloat that behaves very similar to
the Integer variant, except that it handles formatting the value with a
given precision.

2. It adds a callback function to the RadioSettingValue base class,
which allows you to specify a callback function. This function gets
called when the setting is set, is passed the value that is trying to
be set, and expects you to return the value that should actually be
set. This gives you (the driver author) the ability to intercept the
set operation and check the value, optionally raising an exception if
something is wrong (i.e. if their value is not within your 1, 4, 5
requirements).

3. It adds the necessary bits in the UI to catch an error during the
setting save and display it to the user (this really should be there
anyway).

4. It adds a fake setting in uv5r.py to demonstrate how to do this. I
created a new group called "test" with a single fake setting inside
called "footest". This footest setting has a value of type float, which
has a callback called "my_validate". The my_validate() function checks
to make sure the value is not between 200 and 300 returns the value. If
it is in the banned range, it raises an exception saying that it's
invalid.

Hopefully you have a way to apply a patch in your Windows environment.
If not, I think you can use "hg qimport" to pull this into your patch
queue. Test it to see how it works, and maybe try building your new
feature on top of it. If it works (or needs some tweaking) then I can
clean it up and put it in the tree.

Whew, hopefully that all made sense!

--
Dan Smith
www.danplanet.com
KK7DS

_______________________________________________
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