> 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.
True - this is a known issue with no real solution. The initial
exchange information gets saved when the QSO is first logged. The
window editor, being as basic as possible, isn't smart enough to
realize that you have changed the name. Therefore, it doesn't get
updated.
> 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.
I will check into this. While the initial.ex file is still
supported, the TRMASTER.DTA file is the preferred method of
getting initial exchange information.
> 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.
Many contests do this already (SS is a great example) however, the
syntax of the sprint exchange makes it tough to add this function.
Can you tell me what this means: CAL KEN 34 MIC? Per your example
above, that would be Mic in Kentucky giving me #34.
> 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.
Well, it is often handy to enter the call and then press RETURN. This
will do auto dupe checking and all of that. You can then update the
call in the exchange window. You can update the call instead of
going back to the call window if you turn on the CALLSIGN UPDATE
ENABLE feature. This will work for most any exchange format.
> 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.
Hmmm - for as often as you would normally correct callsigns, this
seems like a rather involved process. I will think about it more.
Tree
--
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
|