[DXLog.net - Support] Some notes after CQ WW RTTY

[Dave Zeph]

I used 2.1.8 DEV, Unassisted, only in RUN Mode, and with both MMTTY and
2TONE.  So I can't comment on problems with Spots.  But let me be the 4th to
have experienced problem 2) described by Sergei.  

This ersatz data would sometimes be a single letter, but sometimes a call
from the Receive Window(s).  This would happen before a CALL was typed, and
was not overridden by the STATE lookup from the Call History Database.

Sometimes I would not notice it had occurred until there was a problem
entering the next call.  This was because DXLog would not execute the
embedded $CR to enter the QSO with an invalid STATE Field.  

Or I found I had inadvertently overtyped the CALL of the previous QSO.  I
didn't want to use F11 to WIPE the previous QSO, so I'd move the cursor and
use the SPACE bar to clear the "crud" and cycle the SPACE Bar to get STATE
lookup from the Call History Database.

Another problem that occurred too often was when I'd do S&P in RUN Mode.
The messages are much the same and it was easier to not have to use CTRL-TAB
to switch back and forth.  I'd press ENTER to log the QSO but occasionally
the station would ask for a repeat of his report.  So my cursor would be in
the CALL Field of the new QSO Line and I'd press the INSert Key to resend
the Report.  Sometime my call would suddenly appear in the CALL field of the
new line and my Report would be sent to my call rather than the call of the
station I'd just worked.  I wish I could describe what happens and in what
sequence but it would just "happen" at inconvenient times!

A couple of cases DXLog would not "forget" when QSO Data was entered, but
not logged with an <ENTER> or $CR.  It only happened a couple of times, so I
can't describe how to repeat the glitch.  The only way to get rid of the
line of QSO Data was to overtype the call with my call and log the "QSO" or
to exit and then restart DXLog.

I SHOULD NOT HAVE to also enter my STATE - or ANY OTHER FIELD - when I have
to nullify a QSO by typing my call,.  Entering one's own call is All that
should be necessary.  Now DXLog requires these field to be filled before the
nullified QSO is logged.

Also I second Fabio's entire comments about ALT-K.  I sensed that stuff I
tried to send manually (often a repeat of my State) was not being
transmitted.  Now that I think of it, typing ALT-K would not always result
in sending of Diddles.  And it would be helpful to automate the Manual Send
and then close the Window.   The operator would know when the "send" was
complete.

Finally I second John's observation that MMTTY's ALT-K Button does not
function - and least not when run under DXLog.



---- Dave





-----Original Message-----
From: support-bounces at dxlog.net [mailto:support-bounces at dxlog.net] On Behalf
Of Sergey Dvadnenko
Sent: Monday, 29 September, 2014 7:32
To: DXLog.net Reflector
Subject: [DXLog.net - Support] Some notes after CQ WW RTTY


Hi group! 
I used ver 2.1.7

Problems that have been seen in the last CQ WW: 

1) Spots disappeared from the dx-announcements window Their life was just a
few seconds.
2) When clicking mouse to text in the receiving windows which is not contain
the callsing it always paste the    text to the STATE field. Why if callsign
field is still clear?
3) Toward the end of the contest after the transmiting of macro ( for ex F1)
trcvr did not go to the reception mode.
Sergey UA6AA
_______________________________________________
Support mailing list
Support at dxlog.net
http://www.dxlog.net/mailman/listinfo/support