+++more AA6YQ comments below
--- In dxlab@..., "Jerry Keller" <k3bz@...> wrote:
****K3BZ comments below:
----- Original Message -----
When there's a choice, AddNeeded gives preference to the most recent
QSO found in the Log Page Display.
****Great!
I have two concerns with your suggestion:
1. its not obvious to me that attempting to confirm an arbitrarily-
old QSO with a US manager will be less risky than a QSO made last
week
**** It was my (probably hasty) assumption that QSLing to a manager
in the same country would almost always be less costly and less
risky than to one in a foreign country. Of course, that depends on
the countries involved. DXKeeper must use some initial algorithm to
select Add Needed QSOs, one that's considered "most favorable" to
most users. I was just suggesting my idea of what that might be, and
I didn't know how to check if that was already the algorithm in use.
2. DXKeeper can't reliably determine a Manager's DXCC entity from
his or her callsign; I'd need to add a "Manager's DXCC entity" item
to each QSO, which DXKeeper would populate with its best guess
(based on a callbook lookup, previous QSO, or DXCC database lookup)
but the user could verify and correct if necessary
****Could DXKeeper look at the same things Joe's filter looks at? Or
would that take too much additional time?
+++The problem is ambiguity in the manager's callsign. If you live
in France, and have a QSO whose manager callsign is TO5DX, for
example, would that QSO qualify as "preferred"? TO5DX might live in
france, or she might live in French Polynesia.
Joe's approach, while admittedly requiring two invocations of the
AddNeeded function, illustrates the flexibility of the current
scheme. You can prefilter the Log Page Display to contain
only "ideal" QSOs, whatever your personal definition of "ideal", and
then run AddNeeded with the Log Page Display unfiltered to catch
everything else.
****I find I am a bit of a dunce when it comes to using some of
DXLabs already terrific features, like the filters that give it
flexibility to do just about everything except kiss me goodnight...
and I expect someday Joe will come up with a filter for that, too!
I just never thought of using filters, and I could never have
written THAT one anyway. Next QSL label run, I'll try it, Joe,
thanks very much, I think it might cover what I was concerned with.
I do note that Joe's approach would also benefit from a "Manager's
DXCC entity" item in the log..
**** Expanding DXKeeper's data items never occurred to me. I thought
it could be done with the QSL_Via data we already have.
+++It can be done with QSL_Via, as Joe's filter demonstrates, though
the required expression is verbose, and suffers from the TO5DX
problem.
+++A filter of the form
QSL_VIA_DXCCPREFIX='K'
would be both more accurate and easier to type.
73,
Dave, AA6YQ
