Hmm, yeah, I think that's a bug, and probably pretty confusing to users. However, I expect the intent there was to initialize the settings if you were opening that memory for the first time. So, probably what should happen is:

if extra: set_extra() elif not mem.empty and (mem was empty): initialize_extra()

That last "was empty" part would require looking at the current memory map to see if it looks like a deleted memory.

Jim, does that make sense?

Michael, are you offering to fix up the drivers that behave this way?

Thanks!

--Dan

Dan,

I'm not 100% certain, but I think this is something that I got from Pavel. It didn't seem to be working as expected for my recent driver work so my "fix" was to leave it out.

What you propose makes sense.

Jim

thanks for your hints - in the attached version of btech.py, I tried to implement them. I it's OK from your point of view, I will soft-commit a patch for it (and afterwards try to do the same for the baofeng-common-driver).

It's much easier to read a patch to see what you changed. If you could send that instead it'd be better.

BTW: Should I open a separate issue for each affected driver?

Nah, one for all of them should be fine.

Thanks a lot for working on this!

--Dan

HI,

Investigating #4121 for the UV-5R showed me that there are different causes for this issue, and it would be quite hard for me to find them by reading the sources, so I manually tested all img-files that are available on the repo, with following result:

Alinco DJ175: resets mem.extra after edit of regular settings Alinco DJ596: resets mem.extra after edit of regular settings Alinco DR235T: resets on edit AnyTone OBLTR-8R: no reset of mem.extra, but mem.extra also persitent after deleting/editing memory AnyTone TERMN-8R: no reset of mem.extra, but mem.extra also persitent after deleting/editing memory Baofeng_BF-888: OK Baofeng_F-11: resets mem.extra after edit of regular settings Baofeng_UV-3R: no mem.extra Baofeng_UV-5R: (before my changes) resets mem.extra after edit of regular settings Baofeng_UV-6R: resets mem.extra after edit of regular settings Baofeng_UV-B5: OK Baojie_BJ-9900: no mem.extra BTECH_GMRS-V1: resets mem.extra after edit of regular settings BTECH_UV-2501+220: OK BTECH_UV-5001: OK BTECH_UV-50X3: resets mem.extra after edit of regular settings BTECH_UV-5X3: resets mem.extra after edit of regular settings Feidaxin_FD-268A: editing mem.extra does not work (ERROR: Exception running RadioJob: 'Busy' in logs) Feidaxin_FD-268B: editing mem.extra does not work (ERROR: Exception running RadioJob: 'Busy' in logs) Feidaxin_FD-288B: editing mem.extra does not work (ERROR: Exception running RadioJob: 'Busy' in logs) Icom_IC-208H: no mem.extra Icom_IC-2100H: resets mem.extra after edit of regular settings Icom_IC-2200H: no mem.extra Icom_IC-2720H: no mem.extra Icom_IC-2820H: no mem.extra Icom_IC-Q7A: no mem.extra Icom_IC-T70: no mem.extra Icom_IC-T7H: no mem.extra Icom_IC-T8A: properties-window does not open (with error in the logfiles) Icom_IC-V82_U82: no mem.extra Icom_IC-W32A: no mem.extra Icom_IC-W32E: no mem.extra Icom_ID-31A: no mem.extra Icom_ID-51: no mem.extra Icom_ID-51_Plus: no mem.extra Icom_ID-800H_v2: no mem.extra Icom_ID-880H: no mem.extra Jetstream_JT220M: resets mem.extra after edit of regular settings Jetstream_JT270M: OK Kenwood_TH-D72_clone_mode: no mem.extra Kenwood_TK-272G: OK Kenwood_TK-760G: OK Kenwood_TK-8102: no reset of mem.extra, but mem.extra also persitent after deleting/editing memory KYD_IP-620: no reset of mem.extra, but after delete of a memory, property-window does not open anymore (with error in the logfiles) Leixen_VV-898: OK Leixen_VV-898S: OK LUITON_LT-725UV: resets mem.extra after edit of regular settings Polmar_DB-50M: no mem.extra Puxing_PX-2R: no mem.extra Puxing_PX-777: no mem.extra Puxing_PX-888K: OK Retevis_RT21: resets mem.extra after edit of regular settings TYT_TH-7800: resets mem.extra after edit of regular settings TYT_TH9000_144: no mem.extra TYT_TH-9800: OK TYT_TH-UV3R-25: no reset of mem.extra, but mem.extra also persitent after deleting/editing memory TYT_TH-UV3R: OK TYT_TH-UVF1: Ok Vertex_Standard_VXA-700: no mem.extra. BUT all Settings survive delete of a memory WACCOM_MINI-8900: OK Wouxun_KG-816: OK Wouxun_KG-818: mem.extra can't be edited (OK-Button greyed out) Wouxun_KG-UV6: OK Wouxun_KG-UV8D: no mem.extra Wouxun_KG-UVD1P: OK Yaesu_FT-1802M: no reset of mem.extra, but several settings survive delete of a memory Yaesu_FT-1D_R: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-2800M: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-2900R_1900R: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-50: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-60: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-7800_7900: no mem.extra. But some settings (power, mode) survive delete of a memory Yaesu_FT-817: some settings (power, mode, extra) survive delete of a memory Yaesu_FT-817ND: some settings (power, mode, extra) survive delete of a memory Yaesu_FT-817ND_US: some settings (power, mode, extra) survive delete of a memory Yaesu_FT-857_897:some settings (power, mode, extra) survive delete of a memory Yaesu_FT-857_897_US:some settings (power, mode, extra) survive delete of a memory Yaesu_FT-8800: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_FT-8900: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_FTM-350: no mem.extra, but some settings (power, mode) survive delete (others don't) Yaesu_VX-2: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_VX-3: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_VX-5: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_VX-6: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_VX-7: no mem.extra, but some settings (power, mode) survive delete of a memory Yaesu_VX-8_R: no mem.extra, but some settings (power, mode) survive delete of a memory

So, (besides some other bugs that are not related to this issue) this shows following: - there is no common agreement among the driver-developers on how to handle deleted memories (reset all settings to default, preserve all settings, preserve some ...) - there are many drivers that are affected from this bug, so obviously many developers thought that if a mem.extra is defined, it is supplied always (and not only when using the properties-menu)

For the first point I have no idea - for me personally it seems logic to reset a memory to it's defaults (i.e. all settings) when it's deleted. For the second one, I wonder if it would be possible to just add all the mem.extra-settings as additional columns of the memory-table. That way, the mem.extra would never be empty, and most drivers affected from #4121 would work "out of the box". (And, for me it also seems to be more intuitive to see all properties of a memory on the same screen - but that is again my personal opinion). Do you think this is possible? Or would this cause other drawbacks?

73, Michael