AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 1:38 PM
To: dxlab
Subject: Re: [dxlab] Can't log FR1GV

On Fri, Mar 4, 2016 at 10:29 AM, aa6yq@... [dxlab] <dxlab@...> wrote:

Though the DXCC database update process does inform the user if it is necessary to "recompute" each log and then direct SpotCollector, and though the release note accompanying each DXCC database update includes the required step-by-step instructions, the current situation demonstrates the existence of a "hole" into which too many users are falling.


Our policy here is that all questions are welcome, no matter how many times they have already been asked and answered. When the same question is repetitively asked to the point where it strains our ability to respond in a friendly manner, that's a red flag that there's a latent usability defect in the product.

To correct this defect, I am considering the following changes:

1. DXKeeper will add a new "last DXCC Database version" setting to each log file; this setting will start out "empty"


2. when DXKeeper opens a log file, it will check the "last DXCC
Database version" setting

2a. if the setting is empty, or specifies a DXCC database version other than version of the current DXCC database, DXKeeper will check the log's DXCC progress table for consistency with the currently-installed DXCC database; this consistency check simply confirms that each of the ~400 DXCC entities in the DXCC database is present in the log's DXCC progress table, and with the correct entity prefix.

--- if the DXCC database and DXCC progress table are consistent, the
log's "last DXCC Database version" setting will be updated to reflect
the the DXCC database version

- if the DXCC database and DXCC progress table are not consistent,
the user will be directed to initiate a Recompute operation, and to
then direct SpotCollector to Recompute

2b. if the setting specifies the version of the current DXCC database,
no further action will be taken


3. DXKeeper's Recompute operation will be extended to update the log's
"last DXCC Database version" setting to reflect the the DXCC database
version

These changes will immediately inform a user if the log they open is not consistent with the DXCC Database, enabling the user to take corrective action when convenient.

Is a detectable change to the prefix list the only scenario where a recompute is required (or desirable)?

A change to an entity's "prefix list" does not trigger recomputation. For example, if the prefix TO were allocated exclusively to Martinique and a new version of the DXCC database were released to reflect this change, no recomputation would be required. The existing DXCC progress table entry for Martinique (DXCC entity code 84) and its "entity prefix" FM would remain unchanged.

Three events trigger the need for recomputation:

1. definition of a new DXCC entity

2. deletion of an existing DXCC entity

3. modification of an existing DXCC entity's "entity prefix"

DXCC Database version 2.5.2 contained several examples of event #3, e.g. the "entity prefix" for Reunion Island (DXCC entity code 254) changed from FR-R to FR

Perhaps another approach could be to maintain a "compatible version"
in the DXCC database (updated whenever changes requiring recompute are implemented), and record the version used for the last recompute in the log database. If DXKeeper detects that the version used for the last recompute is less than the compatible version in the current DXCC database, a recompute would be deemed necessary.

A Recomputing a log means clearing all 7 of its realtime award progress tables, and then repopulating those tables associated with awards you're pursuing by examining every QSO in your log. more QSOs in your log, the longer it takes to Recompute. Also, the Recompute function reports inconsistencies and errors it notices while examining each QSO.

The proposed "verify DXCC progress table consistency" function first checks to see if the DXCC database's DXCC table contains the same number of records as the log's DXCC progress table (401 records, at present). If not, the two are inconsistent, and the user is prompted to initiate Recomputation. If the two tables contain the same number of records, then each table is sorted by DXCC entity code and compared to ensure that they specify the same entity prefix for each entity code; if any mismatch is encountered, the two are inconsistent and the user is prompted to initiate recomputation.

Since "consistency verification" is so much faster than recomputation, I'd prefer a scheme in which recomputation is only needed if the log's DXCC progress table is inconsistent with the current DXCC database.

The DXCC database's Settings tab includes a flag that is only set if recomputation is required. Thus the "cost" to users will be

1. the first time you open a log using a version of DXKeeper that supports "consistency verification": the time required to run the "consistency verification" function

2. any subsequent time you open a log using a version of DXKeeper that supports "consistency verification" with a DXCC database whose version has not changed since the last time this log was opened, or whose version has changed but whose "needs recomputation" flag is not set: no cost

3. any subsequent time you open a log using a version of DXKeeper that supports "consistency verification" with a DXCC database whose version haschanged since the last time this log was opened and whose "needs recomputation" flag is set: the time to click the "OK" button in window informing you that recomputation is required.

So the new "consistency verification" function only gets invoked when DXKeeper opens a log whose "database version" setting is empty. After this setting is established, no further "consistency verification" of the log will ever be required, as the DXCC Database's Settings table provides the information required to subsequently inform the user whether Recomputation is required.

73,

Dave,. AA6YQ

On 3/4/2016 1:37 PM, iain macdonnell - N6ML ar@... [dxlab] wrote:

Is a detectable change to the prefix list the only scenario where a
recompute is required (or desirable)?

No, importing a large file of QSOs with "Automatically recompute
realtime award tracking" unchecked would be one scenario under which
a recompute is required/desired as would be running a complex script
(like the "FIX" scripts) that make changes to DXCCid, DXCCprefix,
zone, primary or secondary administrative divisions, grid, etc.

Perhaps another approach could be to maintain a "compatible version"
in the DXCC database (updated whenever changes requiring recompute are
implemented), and record the version used for the last recompute in
the log database. If DXKeeper detects that the version used for the
last recompute is less than the compatible version in the current DXCC
database, a recompute would be deemed necessary.

That is, in effect, what Dave is proposing. He will add "last used"
DXCC Database to the log. If "Last_Used" <> "Current_Version" then
the DXK would compare the 402 (currently) Prefix entries in the log's
Progress table to the same 402 DXXCCPrefix entries in the DXCC table
of the current DXCC Database.

73,

... Joe, W4TV

On 3/4/2016 3:24 PM, John Bastin bastinj@... [dxlab] wrote:

How much is this going to add to the time to load the log when I
startup DXKeeper?

After first updating the DXCC Database version, the compare will not
add any time to the start up (check recorded last version vs. currently
installed DXCC Database version). Even in the initial check, one is
only comparing the ~400 records in the Progress Table against the ~400
prefix records in the DXCC Database so the process should be nearly
instantaneous.

As Dave indicated, performing the Recompute will be optional (user
controlled). However, the "nag" will appear each time DXKeeper is
started until recompute has been run on the log in question.

73,

... Joe, W4TV


On 3/4/2016 3:24 PM, John Bastin bastinj@... [dxlab] wrote:

On Mar 4, 2016, at 13:29, aa6yq@... [dxlab] <dxlab@...> wrote:

To correct this defect, I am considering the following changes:

[large clip of the changes]

These changes will immediately inform a user if the log they open is not consistent with the DXCC Database, enabling the user to take corrective action when convenient.

How much is this going to add to the time to load the log when I startup DXKeeper? It already goes longer than I like to sit and wait (about 147K entries in the log).

Can you make the implementation of this procedure an option that I can leave turned off (since I have no history of not following the recompute instructions that come with a DXCC database update)?

Thanks for your consideration.

73,

John K8AJS
bastinj@...

开云体育

Just installed the new preview build 14279 released this afternoon. DDE is still broken and I have already reported it. System tray is still a mess.

73, Rich - W3ZJ

开云体育

I had decided I was going to keep my mouth shut on this issue, but . . . why start now? ;-)?

One of the reasons I have stuck with this group over the years, and recommended DXLab Suite to friends is because of the excellent support provided. I subscribe to several support groups, and have subscribed to several more in the past. This is the only group I have ever belonged to where a person doesn't get flogged for asking a question. I have never quite understood why someone would subscribe to a support group, and then condemn a person for asking for support.

Any way, thanks, Dave, for keeping this group friendly and cordial. I get a lot of questions answered just by reading the posts. Sometimes I didn't even realize that I had a question until I read the answer here! Keep up the great work. It is appreciated by many. 73.

开云体育

开云体育

My small codeexample which works now in Python3:

import win32ui
import dde

tserver = dde.CreateServer()
tserver.Create("DDEServer")

conversation = dde.CreateConversation(tserver)
print(conversation.ConnectTo)

conversation.ConnectTo("CI-V Commander", 'DDEServer')

data = r"000xcvrfreqmode<xcvrfreq:" + "6" + ">" + "14.080" + "<xcvrmode:" + "4" + ">" + "RTTY"
s = data
datalen = len(data)
conversation.Exec(data)

Hi,

I try to connect via a small Python3 Script to the CI-V Commander via DDE and I am getting "grey" hairs.
I use WinSPY and see that there is traffic inside the DXlab Suite.
I started DXlabTest1.3.5 and TCPIP works
DDE nothing - no value shown.

I tried 2 other test programs - which works - shit - what do I incorrect with my small Python script?

Well - I fall back from CI-V Commander V12.xx (newes) to V11.95 I belive - and voila - DDE is working again in DXLabTest1.3.5 and I may check now what is going wrong with my Python Script

AND NOW it works fine:

I did a lot of investigations - and well - something is wrong in DDE in the newest Commander :)

Now I can go on investigting how to expand for more than only setting the QRG

73 Peter DF1LX

Example for a small DDE Client only setting the QRG to 14080 and RTTY in Python3 (looks easy and very low amount of code or?)

import win32ui
import dde

tserver = dde.CreateServer()
tserver.Create("DDEServer")

conversation = dde.CreateConversation(tserver)
print(conversation.ConnectTo)

conversation.ConnectTo("CI-V Commander", 'DDEServer')

data = r"000xcvrfreqmode<xcvrfreq:" + "6" + ">" + "14.080" + "<xcvrmode:" + "4" + ">" + "RTTY"
s = data
datalen = len(data)
conversation.Exec(data)

On Fri, Mar 4, 2016 at 10:29 AM, aa6yq@... [dxlab]
<dxlab@...> wrote:

Though the DXCC database update process does inform the user if it is necessary to "recompute" each log and then direct SpotCollector, and though the release note accompanying each DXCC database update includes the required step-by-step instructions, the current situation demonstrates the existence of a "hole" into which too many users are falling.


Our policy here is that all questions are welcome, no matter how many times they have already been asked and answered. When the same question is repetitively asked to the point where it strains our ability to respond in a friendly manner, that's a red flag that there's a latent usability defect in the product.

To correct this defect, I am considering the following changes:

1. DXKeeper will add a new "last DXCC Database version" setting to each log file; this setting will start out "empty"


2. when DXKeeper opens a log file, it will check the "last DXCC Database version" setting

2a. if the setting is empty, or specifies a DXCC database version other than version of the current DXCC database, DXKeeper will check the log's DXCC progress table for consistency with the currently-installed DXCC database; this consistency check simply confirms that each of the ~400 DXCC entities in the DXCC database is present in the log's DXCC progress table, and with the correct entity prefix.

--- if the DXCC database and DXCC progress table are consistent, the log's "last DXCC Database version" setting will be updated to reflect the the DXCC database version

- if the DXCC database and DXCC progress table are not consistent, the user will be directed to initiate a Recompute operation, and to then direct SpotCollector to Recompute

2b. if the setting specifies the version of the current DXCC database, no further action will be taken


3. DXKeeper's Recompute operation will be extended to update the log's "last DXCC Database version" setting to reflect the the DXCC database version

These changes will immediately inform a user if the log they open is not consistent with the DXCC Database, enabling the user to take corrective action when convenient.

Is a detectable change to the prefix list the only scenario where a
recompute is required (or desirable)?

Perhaps another approach could be to maintain a "compatible version"
in the DXCC database (updated whenever changes requiring recompute are
implemented), and record the version used for the last recompute in
the log database. If DXKeeper detects that the version used for the
last recompute is less than the compatible version in the current DXCC
database, a recompute would be deemed necessary.

73,

~iain / N6ML

Though the DXCC database update process does inform the user if it is necessary to "recompute" each log and then direct SpotCollector, and though the release note accompanying each DXCC database update includes the required step-by-step instructions, the current situation demonstrates the existence of a "hole" into which too many users are falling.?

Perhaps for future such things, having DXkeeper do something like
open up a window and ask "Recompute the database now?" if it is
needed after an upgrade might safe a few of us poor lids from having
to re-ask FAQ's.

The instruction window that opened when you updated the DXCC database
to version 2.5.5 specifically stated that you would need to Recompute
in both DXKeeper and SpotCollector.

That said, Dave and I have been discussing strategies for automatically
triggering a Recompute - at least in DXKeeper - when necessary. How
and when that is implemented will be up to Dave (of course) but it will
probably be tied to comparing the DXCC Prefix list in the log database
(progress table) to the one in the current DXCC Database. Whether a
mismatch will trigger an automatic recompute with attendant flagging of
invalid subdivision entries and broken entries or only a recommendation
that the user perform a manual Recompute (which will occur every time
the log is opened until the discrepancy is resolved) has still not been
settled.

73,

... Joe, W4TV



On 3/4/2016 11:07 AM, Daniel Brown daniel.h.brown@... [dxlab] wrote:

Joe -

Thanks for the response. It does appear to have fixed the issue.

That said, I'm not sure how I could have guessed that would be the solution
for a brand new contact - when DXKeeper has seemed to be working fine. I
haven't been actively monitoring the group, recently and didn't get
anything when I searched for a few terms around "Reunion" "FR" and
Dxkeeper. Guess I should have dug a bit deeper before assuming I'd get a
friendly and helpful answer back from fellow hams. Perhaps for future such
things, having DXkeeper do something like open up a window and ask
"Recompute the database now?" if it is needed after an upgrade might safe a
few of us poor lids from having to re-ask FAQ's.


73 - Best regards.

N8YSZ.


On Fri, Mar 4, 2016 at 9:30 AM, 'Joe Subich, W4TV' lists@... [dxlab]
<dxlab@...> wrote:

Please review the dozen or more times this question has been asked
in the last few weeks.

You apparently failed to follow the instructions when you last updated
the DXCC database which called for performing a "recompute" to update
the log in DXKeeper in order to reflect the updated DXCC Prefixes.

In DXKeeper, select the "Check Progress" tab then click "Recompute"
in the center of the bottom row. Once that has been completed, you
may also want to perform a recompute in SpotCollector to update any
"old" spots in the Spots database. In SpotCollector, select Config ->
Spot Database and click the Recompute button in the middle of the
right column.

73,

... Joe, W4TV

On 3/4/2016 8:35 AM, Daniel Brown daniel.h.brown@... [dxlab] wrote:

Greetings -

I worked FR1GV the other day on JT65 (yay) but am having trouble
getting it logged with DXKeeper. I keep getting a message that says it
cannot be logged because the QSO contains invalid items. The "DXCC"
field is flashing red when "FR" is selected. FR was automatically
filled by DXKeeper, upon entering the call sign. I changed it to FR-G
(which obviously isn't correct) and of course got an error back from
LOTW when the contact was confirmed.

Any thoughts here?

73, N8YSZ.

OK, I am not fussing at Joe or anybody, he has fussed at me a few times, even when somebody suggested that I ask him directly. I read his post and thought “Go get ‘em Joe.” I also agree with Rich, if the instructions say to recompute, then we should abide by that, especially if you want things to work correctly later in life. Tends to bite you in the ….. if you don’t, always.



Bill, I also envy Joe and others and how they can tell you where to find stuff. I have discovered over the years that when a search routine is written for manuals that you need to learn the terminology they were thinking when they wrote it. Because if you don’t know that you may never find what you are looking for. Rich has given me a couple links that I have bookmarked and I use them quite often, but sometimes I can’t figure out the terminology to ask when I am searching and have to come here to ask, or to Dave.



I have also discovered that despite what some younger folks think getting older is good, in fact VERY good. Because the fix to that is real permanent. Good to see you over here on the reflector too, after DXBase.



73, Bob KB4CL



From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 10:35 AM
To: dxlab@...
Subject: Re: [dxlab] Can't log FR1GV





Bob, the older I get, the harder it is to remember all the myriad of
options in DXLabs.
I envy Joe and the others who help out. I have no idea how they can
remember all of the various DXL settings.

So what I do... when I read a post asking how to fix, or modify, or can
I (insert ? asked), I do a quick check of the settings I have enabled in
that DXLabs module.
Most of the time I find that it's is set properly, but occasionally I
find that I hadn't understood what that option would do correctly and
make the appropriate change. This also offers me the opportunity to
relearn some of the features available but use less frequently than others.

My thanks to both the questioners and those providing the answers. I
learn; (but mostly relearn) some feature I had forgotten.

On 3/4/2016 09:07, 'Bob Main' bobmain1@... [dxlab] wrote:

I think the problem is, for many of us, is we see someone is having a problem. Since we aren’t having it at the time it goes over our heads and we pay little attention to it. Later when we do have the problem it is “OK I vaguely remember somebody had that problem recently, but what did they do to solve it?” Now instead of going back and searching the hundreds (or thousands) of messages it is simply easier, what did they do again? Just my take on this.



73, Bob KB4CL



From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 9:30 AM
To: dxlab@...
Subject: Re: [dxlab] Can't log FR1GV






Please review the dozen or more times this question has been asked
in the last few weeks.

You apparently failed to follow the instructions when you last updated
the DXCC database which called for performing a "recompute" to update
the log in DXKeeper in order to reflect the updated DXCC Prefixes.

In DXKeeper, select the "Check Progress" tab then click "Recompute"
in the center of the bottom row. Once that has been completed, you
may also want to perform a recompute in SpotCollector to update any
"old" spots in the Spots database. In SpotCollector, select Config ->
Spot Database and click the Recompute button in the middle of the
right column.

73,

... Joe, W4TV

On 3/4/2016 8:35 AM, Daniel Brown daniel.h.brown@... [dxlab] wrote:

Greetings -

I worked FR1GV the other day on JT65 (yay) but am having trouble
getting it logged with DXKeeper. I keep getting a message that says it
cannot be logged because the QSO contains invalid items. The "DXCC"
field is flashing red when "FR" is selected. FR was automatically
filled by DXKeeper, upon entering the call sign. I changed it to FR-G
(which obviously isn't correct) and of course got an error back from
LOTW when the contact was confirmed.

Any thoughts here?

73, N8YSZ.

[Non-text portions of this message have been removed]



------------------------------------
Posted by: "Bob Main" <bobmain1@...>
------------------------------------


------------------------------------

Yahoo Groups Links

--
In beautiful downtown Harwood Hts. IL





[Non-text portions of this message have been removed]

--

I know and understand that. In fact I will admit that since I know that is sometimes a requirement when an update comes out that affects the databases the first thing I tend to do is look for the work “recompute”. If I see that then I look more closely to see what and where. Maybe as a user and not a member of the support crew I might be a bit different because I look for just that first.



73, Bob KB4CL



From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 10:45 AM
To: dxlab@...
Subject: Re: [dxlab] Can't log FR1GV





Bob,
The problem is not that people didn't read or remember the solutions to posts on this reflector. The problem is that they didn't read and follow the instructions that were delivered with the database release. If they did, they would never have had the problem in the first place. Some, not all, releases of the DXCC database require one to do a recompute in both DXKeeper and SpotCollector to update the existing databases. That is clearly spelled out in the update instructions. Dave does not do it automatically because it can be time consuming so why waste the time it takes to do it when it is not necessary?

73, Rich - W3ZJ


On 3/4/2016 10:07 AM, 'Bob Main' bobmain1@... [dxlab] wrote:

I think the problem is, for many of us, is we see someone is having a problem. Since we aren’t having it at the time it goes over our heads and we pay little attention to it. Later when we do have the problem it is “OK I vaguely remember somebody had that problem recently, but what did they do to solve it?” Now instead of going back and searching the hundreds (or thousands) of messages it is simply easier, what did they do again? Just my take on this.



73, Bob KB4CL







[Non-text portions of this message have been removed]

开云体育

Bob,
The problem is not that people didn't read or remember the solutions to posts on this reflector. The problem is that they didn't read and follow the instructions that were delivered with the database release. If they did, they would never have had the problem in the first place. Some, not all, releases of the DXCC database require one to do a recompute in both DXKeeper and SpotCollector to update the existing databases. That is clearly spelled out in the update instructions. Dave does not do it automatically because it can be time consuming so why waste the time it takes to do it when it is not necessary?

73, Rich - W3ZJ

Bob, the older I get, the harder it is to remember all the myriad of options in DXLabs.
I envy Joe and the others who help out. I have no idea how they can remember all of the various DXL settings.

So what I do... when I read a post asking how to fix, or modify, or can I (insert ? asked), I do a quick check of the settings I have enabled in that DXLabs module.
Most of the time I find that it's is set properly, but occasionally I find that I hadn't understood what that option would do correctly and make the appropriate change. This also offers me the opportunity to relearn some of the features available but use less frequently than others.

My thanks to both the questioners and those providing the answers. I learn; (but mostly relearn) some feature I had forgotten.

--
In beautiful downtown Harwood Hts. IL