[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] Date bug, worked-window,

From: Rein Couperus PA0R
Subject: Re: [Tlf-devel] Date bug, worked-window,
Date: Mon, 03 Apr 2006 23:01:04 +0200

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:



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:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]