Hi Fabian, tnx for the report and the patch!!
Yes, I would love to program this in perl, would save tons of time:)
Meanwhile I have started to program some perl modules which will form
the basis of a perl version of tlf. I have noticed that my productivity
goes up with a factor of 10 when I program in perl, and extending tlf is
becoming more difficult, especially the wild multiplier and scoring
schemes people come up with to nag the programmer...
In my opinion contest rules should be written in perl, not in C.
That's why I will gradually release perl modules which together will
make a new tlf in the future.
Meanwhile the bugs you found have been repaired, and fresh bits are
waiting to be used in:
http://sharon.esrac.ele.tue.nl/pub/linux/ham/tlf/tlf-0.9.29.tar.gz
or http://wwns.com/tlf/tlf-0.9.29.tar.gz
73,
Rein Pa0R
On Mon, 2006-04-03 at 01:40 +0200, Fabian Kurz wrote:
Hello,
I used tlf-0.9.28 in the SP-DX contest last weekend, works great, no
major problems. I also noticed the spurious characters as reported by
N7XY, sometimes a bit confusing but not really a problem and I trust
it will be fixed.
I found one little bug: The date in the line where the actual QSO is
entered is not continuously updated, so when the clock switched from
23:59 to 00:00 last night, the date remained at 01-Apr-2006; however
when logging new QSOs, it was OK in the last displayed QSOs. In
the entry-line itself it remained wrong.
Looks like the date in this line is only updated by clear_display(),
which will be called sooner or later anyway, but in my case (only
using tlf for logging, not keying etc) it took until half an hour
after midnight or so until it changed.
Adding a clear_display(); to the time_update()-function helped, but
maybe it would be more clever to let time_update itself update the
date aswell, in the same fashion it updates the time.
Another little thing that bothered me during the SP-DX contest was the
way the "Worked"-window works. It always shows the *last* QSO matching
the (partial) call which is entered at the moment on each band.
In SP-DX I worked both SQ9C and later SQ9CAQ on 80m. When I was on
40m and entered "SQ9C", on 80m the QSO for SQ9CAQ was displayed,
because it was the last matching QSO for "SQ9C". I was confused
because I was pretty sure I had SQ9C worked on 80m, and thought I
might have logged him on the wrong band (he was also in log on 160m
:) because he didn't show up in the Worked-window on 80. In my opinion
the "Worked"-window should - if available - display QSOs with exactly
the callsign entered with higher priority than any other matching
callsign.
Of course this is a rare case, only happens when several calls which
have at least the same prefix and a common first suffix letter, but it
bothered me, so I wrote a small patch for searchlog.c to avoid such
confusion:
--%<---
_______________________________________________
Tlf-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tlf-devel