My previous posting on this topic, while accurate, was less than
helpful. Let me try again.
W2UP says:
*****
If the serial numbers were not
assigned until the F-key to send the exchange is pushed, we
wouldn't have any of these out-of-sequence/duplicate/missing
serial numbers.
*****
That would be true if:
1) you never abandoned a QSO after typing the F key
2) you didn't run a multi-PC network
3) you never send a serial number without an F key (e.g. SSB)
The basic problem is that if you start QSO number n, and then
start QSO number n+1, but then QSO n never gets QSL'd, then
there's going to be a gap or duplicate number. There's no way
to avoid that.
The network is a problem because, while it
could be done, I am at least for now, declining to implement
any code that would pre-allocate serial numbers over the
network. The reason for my reluctance is that there would have
to be a central "keeper-of-the-next-serial-number" on the
network, and each PC on the network would have to check out a
number from it during each QSO. Right now, any PC on the network
can make transmissions and log QSOs any time it wants to. It
tells the others after its over, and the others only use that
info for duping. You might think WL's existing network single-
transmitter lockout function already does this. It doesn't.
Each PC sends a message to all other PCs when it starts and
ends each transmission. WL does not actually stop two PCs
from going keydown at once. A PC is locked out during
the time it knows another is transmitting, but if two go
keydown simultaneously, both start. Later (milliseconds
later) WL notices from network messages it has allowed two
transmissions and has a fixed way of choosing which was
wrongly allowed to transmit (the one with the higher network
letter) and aborts the transmission after it started. I don't
see any way to do something similar for serial numbers.
My main reason for defending the existing serial number scheme
is that no matter what WL does, there are going to be gaps or
duplicates in the log. I admit that if WL allocated the serial
numbers a little differently, I could reduce the numbers of
gaps or duplicates. But I just don't see the point of working
on reducing them when I know that they won't go away.
Barry's suggestion to allocate the numbers when the F key is
pressed is a good one--it would reduce the number of duplicate
serial numbers in the final log--but the difficulty of making
the program behave consistently among all the modes has stopped
me.
Another way to reduce, but not eliminate, gaps and duplicates
would be for WL to allocate numbers a bit differently in a
single-PC/two-radio situation like WA9ALS mentioned. When
you have two QSOs in progress on a single PC, WL currently
sends the same serial number on both PCs. A lot of users
are finding this annoying. I can make it send a different
number on those two simultaneous QSOs. But then, when
a QSO never gets logged, there still will be a gap and
a duplicate. I am looking at trying to get such a (simple)
mod into 10.19. But I won't call it a bug fix. Its just
an "annoyance reducer". The "bug"--gaps and duplicates--will
remain.
Wayne, W5XD
--
WWW: http://www.writelog.com/
Submissions: writelog@contesting.com
Administrative requests: writelog-REQUEST@contesting.com
Problems: owner-writelog@contesting.com
|