Re: [chirp_devel] [PATCH] [tg_uv2p] Dont set a priority channel if empty or Broadcast-FM. Fixes fifth issue in #9939
Hi again Dan,
Thanks,
I will modify the fix to have a scan / validate routine as you suggested. Another option would be to have a dynamic value list for the setting (one that is update at every memory access, (e.g. similar to my cached priority list)? As far as I can tell the value lists are static (?) (I guess this is somewhat related to my dependency question in the kepad lock issue)
thanks again, Ran
I will modify the fix to have a scan / validate routine as you suggested. Another option would be to have a dynamic value list for the setting (one that is update at every memory access, (e.g. similar to my cached priority list)? As far as I can tell the value lists are static (?)
I'm not sure what you mean exactly. The drivers should work the same way regardless of how or what order they're called. Meaning something like chirpc that won't fetch or set every memory before letting you tweak one should have the same behavior as the UI which does. The list depends on the current state of the memories, which is why it's not a static list at the top of the file, but built from the memories on the fly, right?
You could build the cached list the first time you need it (if it's not built yet) and keep it coherent with each subsequent get/set call if you want. But, I suspect it's such a tiny amount of data that it's not worth doing that versus just scanning each time, but up to you. I just think it's not reasonable to say "meh, the UI will load all the memories before a set_memory() is ever called so I will have built my list by then" :)
--Dan
Hi Dan, Thanks again, I sent a new patch with a validation routine and an exception upon error
Ran
On Fri, Aug 12, 2022 at 5:37 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
I will modify the fix to have a scan / validate routine as you suggested. Another option would be to have a dynamic value list for the setting
(one that is update at every memory access, (e.g. similar to my cached priority list)?
As far as I can tell the value lists are static (?)
I'm not sure what you mean exactly. The drivers should work the same way regardless of how or what order they're called. Meaning something like chirpc that won't fetch or set every memory before letting you tweak one should have the same behavior as the UI which does. The list depends on the current state of the memories, which is why it's not a static list at the top of the file, but built from the memories on the fly, right?
You could build the cached list the first time you need it (if it's not built yet) and keep it coherent with each subsequent get/set call if you want. But, I suspect it's such a tiny amount of data that it's not worth doing that versus just scanning each time, but up to you. I just think it's not reasonable to say "meh, the UI will load all the memories before a set_memory() is ever called so I will have built my list by then" :)
--Dan _______________________________________________ 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 (2)
-
Dan Smith -
Ran Katz