Bugs:
1) TR will send DUPLICATE QTC's if there are zero point QSO's in the log
(e.g. dupes) and the program is exited and restarted. It appears to read
the qtclist.dat file to determine how many QTC's it has sent and to whom.
Unfortunately, it uses the total as the current location for sending QTC's
in the log.
Suggestion: Also check the last entry in QTC.dat, find that QSO, and
reset the QTC pointer.
2) TR will act squirrely after the "Please send some QTC's,
QTC memory is getting full" warning. It eventually satarted sending
garbage for QTC's, despite my best efforts to send some. :-)
Using TR READ to re-work the contest with a large log causes a core dump.
I suspect this is related.
There is a workarund for re-starting the program...check the last QTC
sent (qtc.dat) and send a series of "fake" QTC's to re-send the
duplicates. This messes up the QTC sent number, but Oh well...
Enhancement Requests:
1) It is FAR too easy to blow away a QTC. Using TR, we just hit <CR>
to do everything. Then the program asks "Did *** QSL QTC ***/**?
(Y/N):" orsomething similar. Quess what <CR> does? It blows
away the entire QTC! This needs to insist on Y/N. Yes, I had to
turn off the radio and re-sent that QTC to nobody!
2) We need to be able to review the QTC just sent, and get the
number (like 172/10) after sending a QTC. Exiting the program to
check QTC.dat causes WAY too much trouble since the QTC's get out
of sync. (Seethe bugs above).
Thanks, Tree! Great program. PLEASE fix these bugs...I complained
about the duplicate QTC's after the 1997 WAE!
73,
Mark
kd4d
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|