That value is meant to only change during band change to avoid messing up
typing into the freq box. It's only used in the one place.
Unless Joe has some other observation it doesn't appear to me that this change
harms anything. Making it an option just means nobody will know to use it to
avoid
Mike,
Thanks for looking at this.
I intentionally proposed an option because Joe had indicated there were reasons
it was implemented to use table frequency rather than current dial frequency.
By implementing as an option those who like the way it works now would see no
change.
I documented a
This small change fixes the problem.Adding this outside the if clause ensures
it is updated with current information...m_freqNominalPeriod = m_freqNominal;
Although we should probably not do pskreporter when the frequency changes like
this as we aren't sure which frequency was decoded.
Mike W9MD
> That's not per the adif specs. this is a Wsjtx defect IMO.
Hi Laurie,
Thanks, agreed, but I am not sure, whether this defect is corrected or not.
Just in case I added that possibility into my mail.
By now I have not seen any response from the originator, is it solved or not?
73, Reino O
Neal,
Guessing you screwed yourself. Bottom line: "don't delete nuttin'" without
backing up.
You likely have not backed up your computer. If you did, you could reload your
worked before files by copying the backed up version of CALL3.TXT to your
current version. [simply copy and paste] I b
On 29/07/2024 4:30 pm, Reino Talarmo via wsjt-devel wrote:
There should not be any empty lines in the middle of the adi file.
That's not per the adif specs. this is a Wsjtx defect IMO.
I have seen many adif files that contain empty lines. Also multi-line
fields like the address, notes, qsl_ms
