+ AA6YQ comments below

If you are using WSJT-X just click in the call area and hit F4 , this clears the call from WSJT-x and DX Labs will follow.

+ On DXView's Main window, clear the "callsign" box and strike the Enter key.

73,

Dave, AA6YQ

+ AA6YQ comments below

I was able to complete my application using only LoTW. It was processed within a couple of hours. No problems downloading or linking DXCC credits in DXKeeper.

+ 100% of DXCC credits granted to LoTW confirmations will auto-link with no manual intervention.

This is the method that is right for me.

+ If you're happy, I'm happy!

73,

Dave, AA6YQ

myqthid.

Make one for every place you have operated from. Do the same in
TQSL's "station locations". Then you can point DXLab's myqthid at the
matching TQSL station location.

--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!

I think I added the new location and grid to LOTW, but I don't find a place to tell DXLabs to use the new location.
Can someone point me in the right direction
--
Norm WA4ZXV EM64or

Hi Dave, 

PTT via Commander works great, thank you. 
Have a similar question, is there a way to make Commander, WinWarbler and WSJT-X working at the same time without adding an extra serial connection for WSJT-X?

73
Den

--

Hey Dave - that ability to connect WSJT-X (or JTDX) + Commander to a remote SpotCollector / DXKeeper [/DXview] is just what the Dr ordered!  Very slick!

That's really all I need for my current operating conditions, thx.  Out of curiosity, are there any other clients that could operate this way (just the client + UDP)?  
If WinWarbler did that I think all modes would be covered for the occasional non-FT8 QSO on the Radio PC.

Thanks and 73,
Rowland K4XD

+ There wasn't, but there is now: I've expanded the "Generating an LoTW Submission" section of
https://www.dxlabsuite.com/dxlabwiki/GenerateSubmission <https://www.dxlabsuite.com/dxlabwiki/GenerateSubmission>
+ to describe and characterize the two alternatives.

Looks good, Dave. Thanks.

I was able to complete my application using only LoTW. It was processed within a couple of hours. No problems downloading or linking DXCC credits in DXKeeper. This is the method that is right for me.

73,
Paul N1BUG

Evidently, that will solve my problem Dave. I should have known!

But still, in the past the <Show Spots>-window stayed as a "part of.." SC-window.

I always was able to copy correct info from that "Show Spots" part right to the Notes box of an outgoing spot.

But i'll handle the (evident) solution you proposed.

Eddy ON5JK

Op 28/07/2021 om 21:24 schreef Dave AA6YQ:

Hi Dave and All,
The integration of DXKeeper with ClubLog Grid Square map works very well, and the resulting feature is really interesting.
To make it perfect, I think that DXK should change the status of ClubLog from Y to M also when there is a modification in the Grid column of DXK: Grid added or modified by LotW, Grid added copying from eQSL or QSL etc.
To check, I reuploaded my ~80K log to ClubLog, merged with existing log, and around 1600 QSO's were modified, reflecting the changes LotW or me made to the Grid column.
73
Franco 3A2MW

+ AA6YQ comments below

Dave i noticed a small inconvenient in my SC.

When i activated "Show Spots of <Callsign> near <QRG> in SSB " the apropriate window apears on top, showing a bunch of former spots.

Usually in the past it was possible to write a reference or so in the "Notes" box of a possible outgoing spot, still showing the window <Show
Spots> thus able to copy an earlier given reference.

Now, when i have the <Show Spots...> visible, and i move the cursor and
click in the box for the "notes for outgoing spots"

the moment i click the window "Show Spots" dissapears. It is no longer
"on top", but hidden by the SC-window.

+ That's correct behavior, Eddy: when you click on a window, it becomes active, and obscures any parts of windows behind it that do not have their "always on top" properties enabled. The "Spots of ..." window has never had its "always on top" property enabled; DXLab applications only enable a window's "always on top" property if that window displays information that the user must immediately see.

So i am not able to copy data from it, in order to generate a new spot with correct references.

+ Position the "Spots of..." window so that it is not behind SpotCollector's Main window.

73,

Dave, AA6YQ

+ AA6YQ comments below

I'll try the approach I outlined above, running a second database on the Office PC and exporting / importing the ADIF's to the master db on the Radio PC.
I don't see a reliable way to automate this export/import but please advise if I've missed something (i.e. a "synch" function that exports/imports new QSO's each time).

+ There is no such "new QSO sync" function; when I asked here about providing this capability several years ago, no one expressed interest. Such a capability would only ensure that a new QSO logged on the remote system was also logged on the local (master) system; it would not propagate changes made to QSOs via the remote instance of DXKeeper, like updating a signal report. I fear this could cause confusion and data loss.

+ If you use the direct interoperation between WSJT-X and DXLab, all you would need on the remote system would be instances of WSJT-X and Commander; QSOs logged via the remote instance of WSJT-X would be conveyed to the local instance of SpotCollector, which would direct the local instance of DXKeeper to log them. See "Installing and Configuring Additional WSJT-X Instances" in 

https://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesDirect

       73,

             Dave, AA6YQ

 

Dave i noticed a small inconvenient in my SC.

When i activated "Show Spots of <Callsign> near <QRG>  in SSB " the apropriate window apears on top, showing a bunch of former spots.

Usually in the past it was possible to write a reference or so in the "Notes" box of a possible outgoing spot, still showing the window <Show Spots> thus able to copy an earlier given reference.

Now, when i have the <Show Spots...> visible, and i move the cursor and click in the box for the "notes for outgoing spots"

the moment i click the window "Show Spots" dissapears. It is no longer "on top", but hidden by the SC-window.

So i am not able to copy data from it, in order to generate a new spot with correct references.

I use to do this, to correct after false "notes" are sent by another OM. (everybody makes mistakes).

Is it a setting that changed on my PC ?

Thanks for great support.

Eddy ON5JK

* If you are using Window Defender Antivirus (Windows 10), update it to its latest malware definition in

https://www.microsoft.com/en-us/wdsi/definitions

before installing or upgrading to DXKeeper 16.2.4


This version

- corrects the error message displayed when attempting to Sync LoTW QSOs or Sync LoTW QSLs with no LoTW account password specified

- corrects a regression in preserving visibility of the Comment/QSLMsg items in the Capture window (tnx to Chuck WS1L, Andy K0AF,
Rien PA7RA, Don WB6BEE, Jim W5ABA, and John K1ESE)

- prevents an errorlog.txt file entry from being generated in state 5 of Capture.NoteMsgToggle_Click (tnx to Chuck WS1L)

- correctly handles double-clicking the letter R in the Mixed column on the Realtime Award Tracking window's IOTA tab (tnx to Aart
PA3C)

- ignores leading and trailing blanks in the items specified in the "Replacement options" panel on the Main window's Import QSOs tab
(tnx to Stewart G0LGS)

- if the "Sync LoTW QSOs" function encounters a duplicate QSO, sets the QSO's Select item to 'Y' (tnx to Glenn W0GJ)

- provides the "Advanced Sorts, Filters, and Modifiers" window's Duplicate filter with a Merge option that harvests information from
duplicate QSOs whose Select items are set to 'Y' and places it into empty items in the QSO whose Select item will not be set to 'Y'
(tnx to Glenn W0GJ)

- provides the "Duplicate Checking" panel on the Main window's "Import QSOs" tab with a "Merge information from each duplicate into
the existing QSO" option that when enabled updates information not present in an existing QSO with information harvested from an
imported duplicate QSO

- when double-clicking a callsign in Commander's Bandspread or Spectrum-Waterfall windows with SpotCollector's "Log Filter" set to
"call" and DXKeeper's "Display previous QSOs on Lookup" disabled, directs DXKeeper to populate its Filter panel textbox with the
double-clicked callsign (tnx to Jim W5ABA)

- includes the GRIDSQUARE and VUCC_GRIDS items when submitting a QSO to Club Log, and recognizes Club Log's new "Updated" response
(tnx to Michael G7VJR)

- updates the FilterLog.htm, Import.htm, QSL.htm, and ViewEditLog.htm documentation files


Notes:

1. Update your firewall and anti-malware applications to consider this new version of DXKeeper to be "safe"

a. JOTTI virus scan: 0 of 15 scanners detected malware in this version's executable

b. VirusTotal: 0 of 69 scanners detected malware in this version's executable

c. submitted to Microsoft for analysis by Windows Defender: no malware detected in this version's executable


2. If this upgrade doesn't work correctly, see the "After an Upgrade" section of
<http://www.dxlabsuite.com/dxlabwiki/ApplicationStoppedWorking>


3. After upgrading, to revert to the previous version of DXKeeper, see
<http://www.dxlabsuite.com/dxlabwiki/RevertApplicationVersion>




DXKeeper 16.2.4 is available via the DXLab Launcher and via

http://www.dxlabsuite.com/download.htm

73,

Dave, AA6YQ

+ AA6YQ comments below

This all worked. The log has been transferred (via Zoom and Dropbox)
to the new Trustee. We even imported 700+ Field Day QSOs and uploaded
them to LOTW. I even discovered a couple things deep in the bowels of
DXKeeper that will smooth those imports for both him and me in the
future (ignore sub-squares, stop deducing).

All the switching of workspaces though made me think of a feature
request. My workspaces had all leaked.

+ What does it mean for a Workspace to leak?

This isn't a big deal if I switch, say, from "N5UWY" to "N5UWY-Lite" since it's the same DB and
the same LOTW creds though with different app settings ... but for the
club call, it was an issue. I've gone through and cleaned them all up
in my installation. Further, I've also made it a new habit to "save
settings" before loading another workspace.

+ The only way to force DXLab application to save its settings to the Windows Registry is to terminate it. Doing this is only necessary if you've made changes to the application's settings since starting it, and you plan to update a Workspace with those changed settings.

I also recommended this
to the new trustee and told him why. My feature request is this: For
a user who has just terminated a workspace and who goes to load a
different one, a dialog box that prompts the user to save the settings
of the workspace they just left. Not sure of the exact sequence of
events, but something that reminds me to save settings before I load
the next workspace would, I think, prevent inter-workspace leakage.
Not much of a problem if you only have a single callsign, but if you
manage club calls, I think it would be helpful.

+ I'll be able to understand this request after you explain the meaning of "Workspace leakage".

Speaking of workspaces, the new trustee was having issues with save
workspaces. Errorlog showed the MSWINSCK.OCX error that others have
mentioned.

+ To what  MSWINSCK.OCX error are you referring?

Found a couple of old list messages that had procedures
that did "something" in that we get a different error now.

+ If there's an errorlog.txt file, please attach it to an email message, and send the message to me via

aa6yq (at) ambersoft.com

    73,

           Dave, AA6YQ

+ AA6YQ comments below

A few small changes:

1) Club Log can now read in extra grids from the VUCC_GRIDS field, allowing more than one grid per QSO. This is to support crossing grids (i.e. QSOs where a station is on the exact boundary of grids).

2) Merging now works. If you upload an ADIF which contains grids etc. then they are merged in. No need to clear your log anymore.

3) Real time logging now returns "Updated" rather than "Dupe" when updates are made to an existing QSO.

Thanks to Dave AA6YQ for the tip about VUCC_GRIDS and Dave, N9FN for his (amazing) test log which helped immeasurably with this.

+ I have updated the next version of DXKeeper to recognize the new "Updated QSO" response from Club Log, and tested it by both uploading a previously-uploaded QSO that specifies a grid square ,and uploading a previously-uploaded QSO that was just confirmed via LoTW; in both cases, the response from Club Log was "Updated QSO.

73,

Dave, AA6YQ

+ AA6YQ comments below

Merely as a personal comment: I am sure somewhere in the DXLab documentation what you explained earlier about the alternate, though potentially more expensive option is duly noted. However, I never found it or failed to understand. Had there been a note in the relevant portion of

http://www.dxlabsuite.com/dxlabwiki/GenerateSubmission

explaining that the procedure can be tedious and noting an alternate method, that might have saved me a lot of time and frustration both in 2016 and in recent weeks

+ There wasn't, but there is now: I've expanded the "Generating an LoTW Submission" section of 

https://www.dxlabsuite.com/dxlabwiki/GenerateSubmission

+ to describe and characterize the two alternatives.

       73,

               Dave, AA6YQ