[TRLog] 3 bugs and ways to make entry slick.

R.S.Hradilek ids@nol.net
Tue, 10 Feb 1998 14:55:47 -0600


This was my first serious attempt to use TRLog, and I found the user
interface awkward. It really killed my rate on 20. I do have 3 specific
bugs to report. They are kind of related. The remaining items are
suggestions for smoothing out the entry of exchange information.

1.  The first time I worked K7BV, I hurriedly typed his name as DENYY. I
then up-arrowed, corrected it to DENNY and saved the changed. The next
time I worked K7BV, his name came up as DENYY again. The earlier
corrected was posted to the log, but not to your table of exchange
information.

2.  W2RQ was in my INITIAL.EX file as BILL, but used the name ROX during
the contest. BILL NJ came up on screen when I entered the call, and I
corrected it to ROX during the QSO. When I worked him on another band,
he came up as BILL again. Settings in INITIAL.EX are overriding the
contacts already in the log. QSO information should default to
INITIAL.EX only if there are no prior contacts.

3.  Snoop Doggy Dog and Tupac Shakur were rappin in the contest from
Washington. The Dog was at N0AX, who was in my INITIAL.EX file as ED.
This means he was brought into my exchange window as ED WA. I completed
the exchange by entering the number and new name, so the exchange window
read "ED WA 207 SNOOP". The contact posted with the name ED, and not
SNOOP. There were two names in the exchange window. The LAST one entered
is the one that should be posted. The same is true for any other
exchange info that is entered more than once. If you were to enhance
your exchange parsing methodology to treat multiple instances of
exchange information as corrections, QSO entry would be much smoother.
It is far easier to re-enter exchange info than it is to backspace over
the original info and retype it. The last instance of QTH, number & name
information would always be the right one. The SIZE of the exchange
window should be extended to the right edge of the screen to accommodate
freestyle corrections and eliminate the need to backspace.

4.  The necessity of entering the callsign in a separate window from the
rest of the exchange information is a severe nuisance. You can parse
this out of the exchange string and recognize it as a callsign because
it is the only part of the QSO with numerics embedded within alphabetic
letters. Tabbing back to the callsign window to correct a call is a real
pain. If you were to accept callsign info in the exchange window, there
would be no need for ANY entry in the callsign window. It could still be
used to display the copied call. If all QSO information could be entered
freestyle into one exchange window and corrected (as in item 3 above),
the user interface would be very slick.

5.  If you have read this far, I have another suggestion that would make
entry even better than slick: In many contests the only exchange
information is a numeric entry (zone, power, qso number, etc.). This
means that all remaining information in the exchange window can be
treated as part of the call. Anything without a numeric digit would be
identified as a call suffix, and anything ENDING in a numeric would be a
prefix. A full call would be mixed numeric and alpha ending with an
alpha character. Anything beginning with a "/" would be appended to the
call, and anything ending with a "/" would precede it. A "/" by itself
would remove any portable designation that was already copied. This
means you could enter only portions of a call that are copied, and only
correct portions of a call that were miscopied. Callsigns (especially on
weak signals) are often copied in bits and pieces. Your logic could
accept them that way and put the pieces together into a complete call
(then dupe check). The option to accept callsigns this way would be
another option in LOGCFG, and would really be elite. I know this
methodology works well because I used it in my homebrew logging software
from 1981 thru ’92. (I understand there are a few callsigns that are
anomalous and would be treated as prefixes and not as full calls: JY1,
TYA11, 5UV386, XW30). I can think of other issues effecting the CW
messages, but won’t go into them here. PLEASE READ THIS PARAGRAPH VERY
CAREFULLY.

I sure hope you read and understand the benefits of these suggestions.

Roy - AD5Q
Sr. Software Engineer
Programming since 1967

PS: calls entered without CAPSLOCK ON display on the screen in upper
case, but are written to the log in lower case.

--
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