[WriteLog] SEQ numbers

[Wayne Wright, W5XD]

This issue has been discussed numerous times over the years.

>Computer #1 - Enter K3XXX in the QSO window, SEQ #1 appears in the window.
>the operator is waiting to enter the report data, at the same time...
>
>Computer #2 - Enters K3AAA in the QSO window, SEQ #1 is assigned to this
>computer also, hence we have two SEQ#1s.

Reasonable people my differ on whether the above is proper behavior by
the program or not, but I want to point out that reasonable people
sometimes also have an impossibility in mind without understanding.

There is only one possible way to guarantee that your log at the end of
the contest will start with SEQ 1 and then have successive QSOs increment
by 1 all the way to the end of the log: you may only have one radio,
one PC (no networking), and one WriteLog Entry Window for the entire
duration of the contest. (The impossibility that some have in mind
is such a log even with multiple radios/PCs.)

So if you have multiple radios and/or PCs, then you have to accept that
your SEQ's won't be sequential. They might be out of order, there might
be duplicates, and there might be gaps (unused numbers). The WriteLog
code makes such choices. You might not like the choices it makes and
other software makes other choices and will give you different SEQ
sequences for identical scenarios. Until someone's log fails to meet
a sponsor's log submitting criteria, WL will continue to assign numbers
as it does today.

A related concept to make this clearer.
A simple rules change would outlaw SO2R. Require a SEQ
number for each QSO and require that the submitted log be exactly
sequential, and assign a penalty for failing to follow this rule. Only
a small penalty would be required to make the second radio useless
regardless of what software you run. (Think about what happens when
you have two QSOs that have been started -- you have sent a number--
but not yet finished--they have not been QSL'd. They must be logged
in order of number--which requires illegal rubber-clocking to get right
and it gets worse if one of the QSOs is never QSL'd. Log checking software
could easily detect people trying to avoid this rule.)

Finally, a technical problem having to do with networking.
Users of WL's networking are probably happy with the fact that if
anything happens to the network, all the local features--including
serial number generation--still run reliably and fast enough to
continue making QSOs no matter what happens on the rest of the network.
If they want WL to coordinate serial number generation across the
network, then they have to also accept the fact that it cannot
be guaranteed to work in the absence of the network. But if that is
the case, then they are willing to live with serial number anomalies
"sometimes". WL currently is built with the reasonaing that if serial
number anomalies are allowed sometimes, its acceptable and much simpler
to have the same anomalies all the time.

Wayne