Transfer a what now?

I have a workspace (and log and TQSL certs) for a club's call. As
soon as I get the paperwork done, I will no longer legally be trustee
for the call or hold the repeater coordinations - yay me!

I need to move the log to the new trustee's system. We expect to do
this by Zoom and Dropbox because it's 2021 and there is no need to be
within 2 m of other humans (we're both vaxxed, but still - Oklahoma's
7-day rolling average was down to about 100 new cases/day around
Memorial Day ... now at 500/day ... and climbing).

The new trustee uses DXLab -- I helped him with his own TQSL setup
within it -- but I'm not sure he has any workspaces configured. Does
a new install set one up or is the default to not set one up? It's
been so long since I first installed the Suite, I don't remember! If
he doesn't have a workspace, I plan to send him to
https://www.dxlabsuite.com/dxlabwiki/CreateUpdateWorkspace and
https://www.dxlabsuite.com/Launcher/Help/RegistrySettings.htm so he
has one for his own call.

Is there a how-to for moving a workspace from one system to another?
I'm going to assume it's something along the lines of "switch to that
ws, save all the settings, switch out, then tar up the directory in
c:/apps/DXLab/Launcher/Workspace" ... Untarring it on his system is
great but how do we get Launcher to see it?

Peter

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

+ AA6YQ comments below

I have a workspace (and log and TQSL certs) for a club's call. As soon as I get the paperwork done, I will no longer legally be trustee for the call or hold the repeater coordinations - yay me!

I need to move the log to the new trustee's system. We expect to do this by Zoom and Dropbox because it's 2021 and there is no need to be within 2 m of other humans (we're both vaxxed, but still - Oklahoma's 7-day rolling average was down to about 100 new cases/day around Memorial Day ... now at 500/day ... and climbing).

The new trustee uses DXLab -- I helped him with his own TQSL setup within it -- but I'm not sure he has any workspaces configured. Does a new install set one up or is the default to not set one up?

+ You must create and populate the Workspace, as described in the article you cite below.

It's been so long since I first installed the Suite, I don't remember! If
he doesn't have a workspace, I plan to send him to https://www.dxlabsuite.com/dxlabwiki/CreateUpdateWorkspace and https://www.dxlabsuite.com/Launcher/Help/RegistrySettings.htm so he has one for his own call.

Is there a how-to for moving a workspace from one system to another?

+ A Workspace is simply a folder containing one file for each DXLab application. It can be copied from one Windows system to another like any other folder.

I'm going to assume it's something along the lines of "switch to that ws, save all the settings, switch out, then tar up the directory in c:/apps/DXLab/Launcher/Workspace" ... Untarring it on his system is great but how do we get Launcher to see it?

+ On the destination system, put the Workspace (folder) in the Launcher's Workspaces folder. The Launcher can reference a Workspace located anywhere on a computer's file system, but it's best to maintain them in one place: the Launcher's Workspaces folder.

73,

Dave, AA6YQ

On Mon, Jul 19, 2021 at 4:20 PM Dave AA6YQ <aa6yq@...> wrote:

Is there a how-to for moving a workspace from one system to another?

+ A Workspace is simply a folder containing one file for each DXLab application. It can be copied from one Windows system to another like any other folder.

I'm going to assume it's something along the lines of "switch to that ws, save all the settings, switch out, then tar up the directory in c:/apps/DXLab/Launcher/Workspace" ... Untarring it on his system is great but how do we get Launcher to see it?

+ On the destination system, put the Workspace (folder) in the Launcher's Workspaces folder. The Launcher can reference a Workspace located anywhere on a computer's file system, but it's best to maintain them in one place: the Launcher's Workspaces folder.

I meant zip, of course. So 1) will Launcher just see the new
directory and "do the right thing", or will he need to set up the
workspace before we put the directory there? 2) Move the DXKeeper MDB
with the club log before or after the workspace shenanigans?

I had never looked at the files in the workspace folders before, what
with fear of black magic and all, and now I see that they are
basically just the Registry entries in plain text. Including LOTW and
TQSL credentials in plain text. :/

Looking at the club DXKeeper stuff in the club workspace, I see my own
LOTW and TQSL credentials in addition to the club's ... what did I do
wrong for that to happen? How can I gracefully clean that up before
the transfer happens?


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

+ AA6YQ comments below

I meant zip, of course. So 1) will Launcher just see the new directory and "do the right thing", or will he need to set up the workspace before we put the directory there?

+ The Launcher's Workspaces window displays the Workspaces present in the current Workspaces folder (which defaults to the Launcher's Workspaces folder). If you move a new folder into the current Workspaces folder while the Launcher is running, terminate and restart the Launcher; the new folder should now be present on the Launcher's Workspaces window.

2) Move the DXKeeper MDB with the club log before or after the workspace shenanigans?

+ I don't understand the question. Please elaborate.


I had never looked at the files in the workspace folders before, what with fear of black magic and all, and now I see that they are basically just the Registry entries in plain text. Including LOTW and TQSL credentials in plain text. :/

+ They are files with a .reg suffix. Be careful: double-clicking one of them in Windows Explorer, and its contents will be loaded into the Windows Registry.


Looking at the club DXKeeper stuff in the club workspace, I see my own LOTW and TQSL credentials in addition to the club's ... what did I do
wrong for that to happen? How can I gracefully clean that up before the transfer happens?

+ I don't understand the first question. In general, to update a Workspace's contents,

1. terminate all DXLab applications except the Launcher

2. make a backup copy of the Workspace folder whose settings you wish to update

3. on the Launcher's Workspaces Window,

3a. select the Workspace whose settings you wish to update

3b. direct the Launcher to load settings from the selected Workspace

3c. start the DXLab applications)whose setting you wish update, use those applications to update the settings as desired, and then terminate those DXLab applications

3d. direct the Launcher to save settings to the selected Workspace

73,

Dave, AA6YQ

On Mon, Jul 19, 2021 at 5:10 PM Dave AA6YQ <aa6yq@...> wrote:

+ The Launcher's Workspaces window displays the Workspaces present in the current Workspaces folder (which defaults to the Launcher's Workspaces folder). If you move a new folder into the current Workspaces folder while the Launcher is running, terminate and restart the Launcher; the new folder should now be present on the Launcher's Workspaces window.

Cool!

2) Move the DXKeeper MDB with the club log before or after the workspace shenanigans?

+ I don't understand the question. Please elaborate.

The whole point of moving the workspace from my PC to the new
trustee's PC is so he can maintain the log for the club station. Do I
not need to bother with the workspace part at all and just Dropbox him
the database? 'Cause that makes the rest of this moot. :-)

I had never looked at the files in the workspace folders before, what with fear of black magic and all, and now I see that they are basically just the Registry entries in plain text. Including LOTW and TQSL credentials in plain text. :/

+ They are files with a .reg suffix. Be careful: double-clicking one of them in Windows Explorer, and its contents will be loaded into the Windows Registry.

c:/apps/DXLab/Launcher/Workspaces contains a number of directories,
one for each workspace as I guess you'd expect. In each of these
directories are files with the name of the various DXL modules. None
of them have .reg extensions (yes, I have "hide extensions" turned off
because that's weird and I'm looking at them in PowerShell in any
case). All appear to *be* Registry entries, e.g.,

REGEDIT4

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXKeeper]

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXKeeper\ADIF]

et cetera so we're talking about the same items regardless of how they
may be named.

Looking at the club DXKeeper stuff in the club workspace, I see my own LOTW and TQSL credentials in addition to the club's ... what did I do
wrong for that to happen? How can I gracefully clean that up before the transfer happens?

+ I don't understand the first question. In general, to update a Workspace's contents,

In the DXKeeper file (no .reg) within the Workspace directory
corresponding to the club's callsign, I find my own callsign in
addition to the club call.

"MarathonInformation-0"="N5UWY"
"LotWUser"="n5uwy"
"n5uwy"="[REDACTED]"

I would like to clean that up in a programmatic way since my
inclination is to go to Windows Subsystem for Linux, and edit the
suckers out of there with vi ... but that's probably not the best way.

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

* AA6YQ comments below

The whole point of moving the workspace from my PC to the new trustee's PC is so he can maintain the log for the club station. Do I not need to bother with the workspace part at all and just Dropbox him the database?

* The database will enable access to the log, but all of DXKeeper's other settings would have to be manually configured.

I had never looked at the files in the workspace folders before, what
with fear of black magic and all, and now I see that they are
basically just the Registry entries in plain text. Including LOTW and
TQSL credentials in plain text. :/

+ They are files with a .reg suffix. Be careful: double-clicking one of them in Windows Explorer, and its contents will be loaded into the Windows Registry.

c:/apps/DXLab/Launcher/Workspaces contains a number of directories, one for each workspace as I guess you'd expect. In each of these directories are files with the name of the various DXL modules. None of them have .reg extensions (yes, I have "hide extensions" turned off because that's weird and I'm looking at them in PowerShell in any case). All appear to *be* Registry entries, e.g.,

REGEDIT4

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXKeeper]

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXKeeper\ADIF]

et cetera so we're talking about the same items regardless of how they may be named.

* My mistake; they contain registry entries, but do not have a .reg file extension.

Looking at the club DXKeeper stuff in the club workspace, I see my own LOTW and TQSL credentials in addition to the club's ... what did I do
wrong for that to happen? How can I gracefully clean that up before the transfer happens?

+ I don't understand the first question. In general, to update a
+ Workspace's contents,

In the DXKeeper file (no .reg) within the Workspace directory corresponding to the club's callsign, I find my own callsign in addition to the club call.

"MarathonInformation-0"="N5UWY"
"LotWUser"="n5uwy"
"n5uwy"="[REDACTED]"

I would like to clean that up in a programmatic way since my inclination is to go to Windows Subsystem for Linux, and edit the suckers out of there with vi ... but that's probably not the best way.

* I strongly advise against directly editing the registry files. Instead,

1. Terminate all DXLab applications except the Launcher

2. Direct the Launcher to load the Workspace

3. Start DXKeeper

4. Use DXKeeper to correct the incorrect settings

5. Terminate DXKeeper

6. Direct the Launcher to save Settings to the Workspace

* Now the Workspace has been updated with your corrected settings

73,

Dave, AA6YQ

On Mon, Jul 19, 2021 at 11:44 PM Dave AA6YQ <aa6yq@...> wrote:

In the DXKeeper file (no .reg) within the Workspace directory corresponding to the club's callsign, I find my own callsign in addition to the club call.

"MarathonInformation-0"="N5UWY"
"LotWUser"="n5uwy"
"n5uwy"="[REDACTED]"

I would like to clean that up in a programmatic way since my inclination is to go to Windows Subsystem for Linux, and edit the suckers out of there with vi ... but that's probably not the best way.

* I strongly advise against directly editing the registry files. Instead,
1. Terminate all DXLab applications except the Launcher
2. Direct the Launcher to load the Workspace
3. Start DXKeeper
4. Use DXKeeper to correct the incorrect settings
5. Terminate DXKeeper
6. Direct the Launcher to save Settings to the Workspace
* Now the Workspace has been updated with your corrected settings

But, but, but ... ASCII !! :-D This is exactly what I realized I
could do and should have been more careful about in the past.

Of the examples I left in above, the only one I can't find (so I can
kill) is the second set of LOTW credentials (my call vs the club
call). Club stuff is there, but so is my own stuff. DXKeeper is the
last cleanup I need to do - the rest of my errors were cleaned up
programatically.



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

Excessive quoting for context since it's been a bit.

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

Speaking of workspaces, the new trustee was having issues with save
workspaces. Errorlog showed the MSWINSCK.OCX error that others have
mentioned. Found a couple of old list messages that had procedures
that did "something" in that we get a different error now. We still
haven't eliminated user error so I'm not yet looking for answers. His
own log is very small, so he was going to export his DB to ADIF, kill
his own workspace and recreate it/import the ADIF. "More details as
they become available"





On Tue, Jul 20, 2021 at 11:28 AM Peter Laws / N5UWY via groups.io
<plaws0@...> wrote:

On Mon, Jul 19, 2021 at 11:44 PM Dave AA6YQ <aa6yq@...> wrote:

In the DXKeeper file (no .reg) within the Workspace directory corresponding to the club's callsign, I find my own callsign in addition to the club call.

"MarathonInformation-0"="N5UWY"
"LotWUser"="n5uwy"
"n5uwy"="[REDACTED]"

I would like to clean that up in a programmatic way since my inclination is to go to Windows Subsystem for Linux, and edit the suckers out of there with vi ... but that's probably not the best way.

* I strongly advise against directly editing the registry files. Instead,
1. Terminate all DXLab applications except the Launcher
2. Direct the Launcher to load the Workspace
3. Start DXKeeper
4. Use DXKeeper to correct the incorrect settings
5. Terminate DXKeeper
6. Direct the Launcher to save Settings to the Workspace
* Now the Workspace has been updated with your corrected settings

But, but, but ... ASCII !! :-D This is exactly what I realized I
could do and should have been more careful about in the past.

Of the examples I left in above, the only one I can't find (so I can
kill) is the second set of LOTW credentials (my call vs the club
call). Club stuff is there, but so is my own stuff. DXKeeper is the
last cleanup I need to do - the rest of my errors were cleaned up
programatically.



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

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

+ 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