Hi !
---------------------
Now as Mike has reported a bug below I will release this mail that I was
writing a while ago. I did not sent it as I could not reproduce bug for
sure. Difference to Mike's observation was that I did not initiate qsos
from wsjtx main window but from companion program. Below is my original
draft mail
--------------------
First of all big thanks for developers. This task is not a small one.
Too big to be "just hobby programming".
Devel list has so many messages that is is impossible to dig out is the
"found bug" already listed.
We should have some kind of "Wall" where someone (not us all) should
collect all bugs.
Bug name | what it does/does not do | is there a workaround | confirm
to be known by developers
That way we could avoid multiple reporting of same bug because reporting
it has variable subjects in devel mails.
I do not know if this bug has been already reported:
When I have called someone but not got qso my std messages are set for
that callsign. If I then choose another CQ caller to try qso with and
double click that line on companion program (cqrlog/CQ-monitor) to start
qso by UDP request sent by the program to wsjtx TX starts but standard
messages are NOT populated with that new call. The previous call is
still there.
Old versions, 1.9.2 and below, never did this. I did not have had time
enough to play with 2.0.0.rc1 and rc2 to see that happen with them.
WSJT-X 2.0.0 rc3, Fedora 28/LXDE, cqrlog 2.3.0-107
--
Saku
OH1KH
Mike kirjoitti 28.10.2018 klo 12.04:
When I was using it with the tx fq locked, when I double clicked on a
new station, the information below did not update and transmitted the
previous station information instead of the station I had just double
clicked.
Haven't succeed making any contacts, but station is not power house
and antennas so-so. Combined with 0 sunspots I am not surprised.
73,
Mike
AK7ML
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
