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!