<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">HELP, please. I sent an earlier version of this message last week, but haven’t seen it in _devel list. I still am soliciting some pointers/help. I still work on the Yaesu FT1D radio, adding in multiple special memories and some digital settings and correcting a setting setup error that exists in the present FT-1D driver.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><div class="">However, I cannot understand what I’ve done to the driver to cause the following problem. I KNOW the problem is my fault, because CHIRP_next does the change correctly, while it behaves incorrectly as described below when CHIRP_next is loaded with my modified driver. As a non-Python-er, I’ve even tried to interact with the driver while running, but haven’t a clue where to look or what to modify to get the output that’ll point to the problem.</div><div class="">[I include a debug file from that CHIRP_next test.]</div><div class=""><br class=""></div><div class="">Bottom line request for help: How can I have affected the UI without having messed up my driver's structures? Or CHIRP’s mem structure either, AFAICT. Any guesses, please? </div><div class=""><br class=""></div><div class="">This UI silliness occurs in spite of the driver passing all tox tests for it:</div><div class="">tox shows no syntax errors in the pep8 section, and </div><div class="">tox -e driver -- -k Yaesu_FT-1D_R</div><div class="">Indicates that my changed driver passes all tests (well, 31 passed and two skipped.)</div><div class=""><br class=""></div><div class="">When I load a bare FT1D file (presumably factory-fresh; actually a default file from Yaesu’s ADMS software for the FT-1D), the expected shows in the CHIRP UI:</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>Memory 1 (first slot, python index 0) has an entry of 145 MHz, FM</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>Eleven “Home" memories are defined as described in the manual.</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>The other 1100 memories show as empty</div><div class="">[Although the files won’t show in the email summary, I attach two screenshots of that situation, both file labels showing “Bare FT1D”, but have removed them from this reprise.]</div><div class=""><br class=""></div><div class="">AFTER attempting to change the second memory slot (python index 1) to show 146 MHz, I expected the UI to auto-populate the rest of the line similar to what showed on the first memory (FM…). BUT:</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>Memory 2 UI now shows a label with an asterisk (almost surely indicating a change to that line) with the 146 I typed still in the frequency location; the rest of the line is blank</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>Home3 (!) UI now shows the correct Memory 2 line, along with label “2”, as if it were memory 2</div><div class="">[Two more screenshots labeled with “after mem 1 change” are no longer included but available.]</div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>Looking at the browser, memory index 1 and Home1, Home2 and Home 3 all show the correct register information.</div><div class="">[Two more screenshots after the changed include “browser” in the filename are no longer included.]]</div><div class=""><br class=""></div><div class="">-<span class="Apple-tab-span" style="white-space:pre"> </span>This type of problem occurs for every memory line up through 100, although it starts to populate the PMS specials memory lines.</div><div class=""><br class=""></div><div class="">BUT: If I save the file, exit and restart CHIRP, everything is in the ‘correct’ place. That’s in keeping with the browser having shown the correct data in the correct place!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Debug file, shows information from unmodified FT-1D module, and then the modified one after “load module”:</div><div class=""></div></div></div></div></body></html>