Topics

One computer - multiple users


Steve W5GP
 

My XYL and myself share the shack computer.  We each have our own account on a Windows 10 laptop.  This has worked well because it keeps our DXLAB (and other) keys separate in the registry and we don't have to perform a user switch via workspaces.  But.....I thought I'd try out user switching to see if it could simplify the Windows environment.   This also worked well with one exception.  The LogPathname key was not being updated in the registry when I'd perform a LOAD ALL from the Launcher.  In other words, if I was the last user of DXLAB and then loaded my XYL's workspace, all keys were updated in the registry except 'LogPathname' and 'Logdirectory' so the next run of DXKeeper would still use MY log but all other configuration items were hers.   The perhaps unusual detail about our logs is that they reside on a NAS so the registry keys point to the network path like "LogPathname" =   "//SERVER/Ham/W5GP.mdb".  As an experiment,  I mapped a network drive to the NAS share that contains our databases, put that in DXKeeper and Launcher, resaved our workspaces and then everything worked like I expected.   So the only thing that appears to not be working is the Launcher not processing the network path name as expected.   Obviously not a big deal but I thought I'd mention it.

73, Steve W5GP


Dave AA6YQ
 

+ AA6YQ comments below

My XYL and myself share the shack computer. We each have our own account on a Windows 10 laptop. This has worked well because it keeps our DXLAB (and other) keys separate in the registry and we don't have to perform a user switch via workspaces. But.....I thought I'd try out user switching to see if it could simplify the Windows environment. This also worked well with one exception. The LogPathname key was not being updated in the registry when I'd perform a LOAD ALL from the Launcher. In other words, if I was the last user of DXLAB and then loaded my XYL's workspace, all keys were updated in the registry except 'LogPathname' and 'Logdirectory' so the next run of DXKeeper would still use MY log but all other configuration items were hers. The perhaps unusual detail about our logs is that they reside on a NAS so the registry keys point to the network path like "LogPathname" = "//SERVER/Ham/W5GP.mdb".

+ Try

\\SERVER\Ham\W5GP.mdb

+ I just set the Launcher's "Startup parameters" panel to

\\Eight\c\DXLab\DXKeeper\Databases\AA6YQ.mdb

+ and then directed the Launcher to start DXKeeper. When started by the Launcher, DXKeeper correctly opened the log on my Windows 8 test system.

73,

Dave, AA6YQ


Steve W5GP
 

Sorry, my original post shows forward slashes by mistake.  They are actually back slashes.  Anyway, the problem occurs when I direct Launcher to LOAD ALL from the workspace.  At that point the startup parameters in Launcher are not loaded with new logpath.  Typing the network logpath into the Launcher startup parameters or within DXKeeper Log parameters works fine.  Just when I direct Launcher to LOAD new parameters from a saved workspace does the problem arise.

73,  Steve W5GP


On Thu, Oct 29, 2020 at 07:13 PM, Dave AA6YQ wrote:

+ AA6YQ comments below

My XYL and myself share the shack computer. We each have our own account on a Windows 10 laptop. This has worked well because it keeps our DXLAB (and other) keys separate in the registry and we don't have to perform a user switch via workspaces. But.....I thought I'd try out user switching to see if it could simplify the Windows environment. This also worked well with one exception. The LogPathname key was not being updated in the registry when I'd perform a LOAD ALL from the Launcher. In other words, if I was the last user of DXLAB and then loaded my XYL's workspace, all keys were updated in the registry except 'LogPathname' and 'Logdirectory' so the next run of DXKeeper would still use MY log but all other configuration items were hers. The perhaps unusual detail about our logs is that they reside on a NAS so the registry keys point to the network path like "LogPathname" = "//SERVER/Ham/W5GP.mdb".

+ Try

\\SERVER\Ham\W5GP.mdb

+ I just set the Launcher's "Startup parameters" panel to

\\Eight\c\DXLab\DXKeeper\Databases\AA6YQ.mdb

+ and then directed the Launcher to start DXKeeper. When started by the Launcher, DXKeeper correctly opened the log on my Windows 8 test system.

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6QY comments below

Sorry, my original post shows forward slashes by mistake. They are actually back slashes. Anyway, the problem occurs when I direct Launcher to LOAD ALL from the workspace. At that point the startup parameters in Launcher are not loaded with new logpath.

+ Did you terminate and restart the Launcher after directing the Launcher to "Load All" from the workspace?

73,

Dave, AA6YQ


iain macdonnell - N6ML
 

On Thu, Oct 29, 2020 at 6:06 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6QY comments below

Sorry, my original post shows forward slashes by mistake. They are actually back slashes. Anyway, the problem occurs when I direct Launcher to LOAD ALL from the workspace. At that point the startup parameters in Launcher are not loaded with new logpath.

+ Did you terminate and restart the Launcher after directing the Launcher to "Load All" from the workspace?
I was able to reproduce this issue. If a path containing
\\server\path\to\database.mdb is specified as the DXKeeper Log under
Startup parameters, the settings saved to a workspace, when settings
are loaded from that workspace, the DXKeeper Log setting does not get
restored. Repeating the test with a path that does not use backslashes
works as expected - the setting is restored (with no restart needed).

Maybe the backslashes are getting interpreted as escape characters somewhere?

A possible workaround for this is to use "Map network drive..."
(right-click on Network in a file explorer window), then use the
drive-based path (e.g. S:\Ham\W5GP.mdb)

73,

~iain / N6ML


Steve W5GP
 

Yes. The logpath doesn't change after a Launcher restart.

73, Steve W5GP


On Thu, Oct 29, 2020 at 08:06 PM, Dave AA6YQ wrote:
+ AA6QY comments below

Sorry, my original post shows forward slashes by mistake. They are actually back slashes. Anyway, the problem occurs when I direct Launcher to LOAD ALL from the workspace. At that point the startup parameters in Launcher are not loaded with new logpath.

+ Did you terminate and restart the Launcher after directing the Launcher to "Load All" from the workspace?

73,

Dave, AA6YQ


Steve W5GP
 

Thanks for the confirmation, Iain.  As I mentioned in my original post I did try mapping a drive letter to the path and that worked fine.

73, Steve W5GP


On Thu, Oct 29, 2020 at 08:22 PM, iain macdonnell - N6ML wrote:
On Thu, Oct 29, 2020 at 6:06 PM Dave AA6YQ <@AA6YQ> wrote:

+ AA6QY comments below

Sorry, my original post shows forward slashes by mistake. They are actually back slashes. Anyway, the problem occurs when I direct Launcher to LOAD ALL from the workspace. At that point the startup parameters in Launcher are not loaded with new logpath.

+ Did you terminate and restart the Launcher after directing the Launcher to "Load All" from the workspace?
I was able to reproduce this issue. If a path containing
\\server\path\to\database.mdb is specified as the DXKeeper Log under
Startup parameters, the settings saved to a workspace, when settings
are loaded from that workspace, the DXKeeper Log setting does not get
restored. Repeating the test with a path that does not use backslashes
works as expected - the setting is restored (with no restart needed).

Maybe the backslashes are getting interpreted as escape characters somewhere?

A possible workaround for this is to use "Map network drive..."
(right-click on Network in a file explorer window), then use the
drive-based path (e.g. S:\Ham\W5GP.mdb)

73,

~iain / N6ML


Dave AA6YQ
 

+ AA6YQ comments below

Yes. The logpath doesn't change after a Launcher restart.

+ Thanks, Steve.

+ The current version of the DXLab Launcher doesn't correctly save settings containing "UNC filenames" like

\\SERVER\Ham\W5GP.mdb

+ Iain N6ML, you are correct; it's an "excaping" issue.

+ I have corrected this defect in the next version of the Launcher, and sent it to you both. Please let me know how it goes.

73,

Dave, AA6YQ


Steve W5GP
 

Thanks for correcting the issue Dave.  In testing user switching I've discovered another problem concerning SQL Filters in DXKeeper.  If User 1 has, for example, a SQL Filter 11 but User 2 has NEVER had a Filter 11, then User 2 will inherit the Filter 11 from User 1 after a user switch.  The reason I say 'NEVER' is because if User 2 blanks out the inherited Filter 11 from User 1 AND resaves his workspace, the problem doesn't reoccur.  It appears that when saving a workspace, the Launcher does not save a "blank" filter to the workspace UNLESS that filter has been manually spaced out.  Hope that makes sense.

73, Steve W5GP


On Fri, Oct 30, 2020 at 12:16 AM, Dave AA6YQ wrote:
+ AA6YQ comments below

Yes. The logpath doesn't change after a Launcher restart.

+ Thanks, Steve.

+ The current version of the DXLab Launcher doesn't correctly save settings containing "UNC filenames" like

\\SERVER\Ham\W5GP.mdb

+ Iain N6ML, you are correct; it's an "excaping" issue.

+ I have corrected this defect in the next version of the Launcher, and sent it to you both. Please let me know how it goes.

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

Thanks for correcting the issue Dave. In testing user switching I've discovered another problem concerning SQL Filters in DXKeeper. If User 1 has, for example, a SQL Filter 11 but User 2 has NEVER had a Filter 11, then User 2 will inherit the Filter 11 from User 1 after a user switch. The reason I say 'NEVER' is because if User 2 blanks out the inherited Filter 11 from User 1 AND resaves his workspace, the problem doesn't reoccur. It appears that when saving a workspace, the Launcher does not save a "blank" filter to the workspace UNLESS that filter has been manually spaced out. Hope that makes sense.

+ Thanks! That's the result of a defect in DXKeeper. I have corrected this defect in the next version of DXKeeper, and sent it your way. Please let me know how it goes.

73,

Dave, AA6YQ