Funny - there seems to be the fault in DXlablauncher somehow - cannot
imagine why - but it is reproducable.

Is Launcher set to start Commander in "Run as Administrator" mode - or
are you using "run as administrator" to launch the stand alone version
of Commander?

You *can not* mix administrator and user modes - run *all* DXLab
components with normal (non-elevated user) permissions. Any program
that needs to exchange DDE with Commander *must also* run with normal
user permissions - not as administrator.

73,

... Joe, W4TV


On 3/4/2016 6:10 PM, pkfalkensee@... [dxlab] wrote:

Well - I use Windows7 (Windows10 - no thanks) - no software update since several month.
- I do not use any antimalware Software - sorry -
I do not use any Internetsecurity Suite - sorry too
Windows Security Essentials is switched off.
Firewall is activated. Brain is working :)

I just switched back to 12.15 and DDE is working. But I started 12.15 Commander without DXlabLauncer.
Now I made a test:
Started DXlabLauncher (2.06) and started CMD -> 12.15 starts up. I fired DXlabTest1.3,5 and NO DDE is possible.
I killed Commander and Launcher -> started Commander "standalone" -> DDE is working with DXlabTest again.
Funny - there seems to be the fault in DXlablauncher somehow - cannot imagine why - but it is reproducable.

Greetings Peter DF1LX

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 6:10 PM
To: dxlab@...
Subject: RE: [dxlab] DDE Changes? CI V Commander V12.xx do not work - V11.9x works

Well - I use Windows7 (Windows10 - no thanks) - no software update since several month.
- I do not use any antimalware Software - sorry - I do not use any Internetsecurity Suite - sorry too Windows Security Essentials is switched off.
Firewall is activated. Brain is working :)

I just switched back to 12.15 and DDE is working. But I started 12.15 Commander without DXlabLauncer.
Now I made a test:
Started DXlabLauncher (2.06) and started CMD -> 12.15 starts up. I fired DXlabTest1.3,5 and NO DDE is possible.
I killed Commander and Launcher -> started Commander "standalone" -> DDE is working with DXlabTest again.
Funny - there seems to be the fault in DXlablauncher somehow - cannot imagine why - but it is reproducable.

Windows will not allow two applications to communicate via DDE unless they have the same privilege level. If one application is started with "Run as Administrator" and the other application is not started with "Run as Administrator", they will be unable to communicate via DDE.

73,

Dave, AA6YQ

Well - I use Windows7 (Windows10 - no thanks) - no software update since several month.
- I do not use any antimalware Software - sorry -
I do not use any Internetsecurity Suite - sorry too
Windows? Security Essentials is switched off.
Firewall is activated. Brain is working :)

I just switched back to 12.15 and DDE is working. But I started 12.15 Commander without DXlabLauncer.
Now I made a test:
Started DXlabLauncher (2.06) and started CMD -> 12.15 starts up. I fired DXlabTest1.3,5 and NO DDE is possible.
I killed Commander and Launcher -> started Commander "standalone" -> DDE is working with DXlabTest again.
Funny - there seems to be the fault in DXlablauncher somehow - cannot imagine why - but it is reproducable.

Greetings Peter DF1LX

开云体育

Hi Dave -

I think that's a great idea.

The nice thing about this reflector is that all questions are welcome, and the majority of people follow your lead and no one gets flamed.

Thanks for setting such a good example for all of us.

73,

Bob WB2NVR

-- 
Bob Schaps  WB2NVR

914-347-7331  Office
914-262-3535  Cell
914-472-0690  Home

AA6YQ comments below

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

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.

One could speculate as why people do this, but this isn't the "Psychology of Online Interaction" group. Suffice it to say that a group where questions are actively welcomed and nasty responses are not tolerated produces an environment that's enjoyable for both new and experienced users -- just what's needed to keep driving the product forward.

73,

Dave, AA6YQ

AA6YQ comments below

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




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).

I don't know yet, John, but it will be a one-time cost. Once a log's "last DXCC database version" setting has been initialized,

it will never again be necessary to invoke the consistency checker.

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)?

Since it's a one-time cost, I don't think that's necessary.

73,

Dave, AA6YQ

On Fri, Mar 4, 2016 at 2:09 PM, 'Joe Subich, W4TV' lists@...
[dxlab] <dxlab@...> wrote:

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.

It's not the same. In my proposal, the need for recompute would be
determined by the database maintainer (you), rather than by DXKeeper
at runtime. I think it would be simpler to implement, faster to
execute, and gives you the flexibility to decide when recompute is
appropriate or not.

73,

~iain / N6ML

AA6YQ comments below

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

I would suggest that you would create a script to automatically do the recompute when there is a change to the underlying database. This would stop people from having to do it manually after the updates and would insure that the information is correct.

Though adding a DXCC entity, removing a DXCC entity, or changing a DXCC entity's "entity prefix" are all relatively rare events, I am very reluctant to have them automatically trigger a recomputation that would stop a user from employing DXKeeper for multiple minutes, depending upon the number of QSOs present in the log and the number of awards being pursued. The user should be informed each time the log is opened that recomputation is required, but initiating recomputation should remain something the user does at his or her convenience.

73,

Dave, AA6YQ

AA6YQ comments below

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

I think this will stop some questions about the recompute after an database upgrade, from what I remember only it's need if some prefix change.
Can/Would the DXCC database version be show above the Recompute button in DXKeeper, Check Progress tab, in bold like DXCC 2.5.2 ?
This would be easier to the user determine what DXCC database version he's running, instead of going to the DXView Config window, database tab.

Clicking the "Database Info" button at the bottom of the General tab of DXKeeper's configuration window displays the versions of all databases in use, including the DXCC database version.

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Friday, March 04, 2016 2:00 PM
To: dxlab@...
Subject: [dxlab] DDE Changes? CI V Commander V12.xx do not work - V11.9x works

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 :)

Since every DXLab application interoperates with Commander via DDE and there have been no reports here of interoperation failures, Peter, that's unlikely. What's more likely is that one of your anti-malware apps is preventing your application from interoperating with the current version of DDE, or perhaps that you're running on a version of Windows 10 that doesn't correctly support DDE.

73,

Dave, AA6YQ

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)