开云体育

This started happening recently.

When I start up PF from DXL (along with the other applications) and enter a call into the Capture window and hit "lookup", PF does nothing.

Doing nothing otherwise, if I terminate PF and restart PF again it functions properly (it looks up the QRZ page for the callsign that was in the Capture window when the Enter key was hit.)

Don
WB6BEE

+ AA6YQ comments below

This started happening recently.

When I start up PF from DXL (along with the other applications) and enter a call into the Capture window and hit "lookup", PF does nothing.

Doing nothing otherwise, if I terminate PF and restart PF again it functions properly (it looks up the QRZ page for the callsign that was in the Capture window when the Enter key was hit.)

+ As a first diagnostic step, please reboot Windows,?

+ Any change in behavior?

? ? ? 73,

? ? ? ? ? ? Dave, AA6YQ

Dave

I re-boot every night.? ?This occurs on start up.

Another interesting part.

If I enter a call into Capture and hit "lookup"? PF does nothing.? ?At that point, if I go to DXV and hit the "QRZ" button at the bottom of the DXV window, PF will go to that call's QRZ page.??

If I enter a second call into Capture and hit "lookup, PF does nothing and stays on the first callsign.

If I terminate PF and restart PF, it will act normally and will go to whatever call in in the Capture when "lookup" is implemented.

Don

+ AA6YQ comments below

I re-boot every night.? ?This occurs on start up.

Another interesting part.

If I enter a call into Capture and hit "lookup"? PF does nothing.? ?At that point, if I go to DXV and hit the "QRZ" button at the bottom of the DXV window, PF will go to that call's QRZ page.??

If I enter a second call into Capture and hit "lookup, PF does nothing and stays on the first callsign.

If I terminate PF and restart PF, it will act normally and will go to whatever call in in the Capture when "lookup" is implemented.

+ After you next reboot Windows and start both DXKeeper and Pathfinder, but before you enter a callsign in DXKeeper's Capture window, take a look at the title bar in DXKeeper's Main window. What letters appear between the square brackets?

+ After you terminate and restart PF, do lookups initiated from DXKeeper continue to work correctly?

? ? ?73,

? ? ? ? ? ?Dave, AA6YQ

?

See email with screenshot

Don

On Thu, Jun 6, 2024 at 01:36 PM, wb6bee wrote:

When I start up PF from DXL (along with the other applications) and enter a call into the Capture window and hit "lookup", PF does nothing.

I have nearly the same behavior , but there is an error mesg

After restarting PF all is ok

73 Alex

+ AA6YQ comments below

On Thu, Jun 6, 2024 at 01:36 PM, wb6bee wrote:

When I start up PF from DXL (along with the other applications) and enter a call into the Capture window and hit "lookup", PF does nothing.

I have nearly the same behavior , but there is an error mesg

After restarting PF all is ok

+ In your screenshot, the title bar of DXKeeper's Main window does not show the letters PF between the square brackets, which means that as far as DXKeeper is concerned, Pathfinder is not running.

+ The possibilities are:

1. Windows is overloaded, and not conveying messages between DXKeeper and Pathfinder.

2. Your anti-malware is interfering with communications between DXKeeper and Pathfinder.

+ As a first diagnostic step, reboot Windows, and then start your DXLab application. Do the letters PF appear between the square brackets in DXKeeper's Main window's title bar? Does entering a callsign into the Capture window cause Pathfinder to perform a lookup operation?

? ? ? 73,

? ? ? ? ? Dave, AA6YQ

?

On Sun, Jun 9, 2024 at 10:44 AM, Dave AA6YQ wrote:

+ As a first diagnostic step, reboot Windows, and then start your DXLab application. Do the letters PF appear between the square brackets in DXKeeper's Main window's title bar? Does entering a callsign into the Capture window cause Pathfinder to perform a lookup operation?

Its only with the first start, its a new behavior within the last days. Yes the entering callsign cause Pathfinder lookup operation, but error messages returns. When I go to the Pathfinder windows I can enter a callsign manually and get a good return.
73 Alex

# more AA6YQ comments below

On Sun, Jun 9, 2024 at 10:44 AM, Dave AA6YQ wrote:

+ As a first diagnostic step, reboot Windows, and then start your DXLab application. Do the letters PF appear between the square brackets in DXKeeper's Main window's title bar? Does entering a callsign into the Capture window cause Pathfinder to perform a lookup operation?

Its only with the first start, its a new behavior within the last days. Yes the entering callsign cause Pathfinder lookup operation, but error messages returns. When I go to the Pathfinder windows I can enter a callsign manually and get a good return.

# Please answer the first question posed above.

? ? ?73,

? ? ? ? ? Dave, AA6YQ

Not at the first start, as shown above

tnx
73 Alex

+ AA6YQ comments below

Not at the first start, as shown above

+ If DXKeeper is unable to connect with Pathfinder after you've rebooted Windows into "Safe Mode with Networking", then anti-malware or another application autmatically started by Windows (when booted normally) are not responsible.

+ The mechanism that DXLab applications employ to interoperate (DDE) is provided by Windows. Since this misbehavior began independently of a new DXKeeper or Pathfinder release, I can only speculate that some other change to? your operating environment is responsible.

? ? ?73,

? ? ? ? ? ?Dave, AA6YQ

No problem at all, I do not autostart now with the other programms and start it by hand after all, that works for me?
73 ALex

I, too, had this same Pathfinder (PF) issue beginning last month. I'd simply close the PF session, launch a new session of PF and all would work well for the rest of the day. As many reported on this forum the PF issue continued to recur daily upon initialization of the DXLabs suite. It was not a showstopper for me, but simply a minor annoyance, along with the repetitive alert popup window that TQSL was unable to function with LoTW being offline.

I got to thinking that the TSQL alert and the initial, stalled attempt of launching the PF session were somehow related, so I navigated to the TQSL tab of the DXKeeper QSL Configuration window and un-ticked all user option variables there. Most importantly (to my thinking) I erased the TQSL.exe pathname variable. While I was in this "pruning mode" I changed the TQSL Username variable to "nobody" and erased the station location and station callsign variables as well. Yes, I admit that the shotgun approach is not very scientific and maybe, just maybe all that was necessary was to remove the TQSL.exe pathname. My reasoning was that if DXKeeper didn't know where that executable resided it wouldn't invoke it, but if TQSL.exe was indeed invoked then the poor, orphaned executable would waste limited resources available to other DDE calls.? If the DDE call to TSQL was of a higher priority or simply the first in the queue of DDE calls then PF (if it were next in queue or priority) would suffer from inadequate resources or an open channel and hang.

Just a guess, mind you, but is this a possible bottleneck scenario resulting in PF misbehaving. Your thoughts, Dave.

Thanks! And by the way Dave, the DXLabs suite is a gem of brilliant programming.
Joe WA3JR

+ AA6YQ comments below

I, too, had this same Pathfinder (PF) issue beginning last month. I'd simply close the PF session, launch a new session of PF and all would work well for the rest of the day. As many reported on this forum the PF issue continued to recur daily upon initialization of the DXLabs suite. It was not a showstopper for me, but simply a minor annoyance, along with the repetitive alert popup window that TQSL was unable to function with LoTW being offline.

I got to thinking that the TSQL alert and the initial, stalled attempt of launching the PF session were somehow related, so I navigated to the TQSL tab of the DXKeeper QSL Configuration window and un-ticked all user option variables there. Most importantly (to my thinking) I erased the TQSL.exe pathname variable. While I was in this "pruning mode" I changed the TQSL Username variable to "nobody" and erased the station location and station callsign variables as well. Yes, I admit that the shotgun approach is not very scientific and maybe, just maybe all that was necessary was to remove the TQSL.exe pathname. My reasoning was that if DXKeeper didn't know where that executable resided it wouldn't invoke it, but if TQSL.exe was indeed invoked then the poor, orphaned executable would waste limited resources available to other DDE calls.? If the DDE call to TSQL was of a higher priority or simply the first in the queue of DDE calls then PF (if it were next in queue or priority) would suffer from inadequate resources or an open channel and hang.

Just a guess, mind you, but is this a possible bottleneck scenario resulting in PF misbehaving. Your thoughts, Dave.

+ Did clearing the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab eliminate the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior?

+ DXKeeper does not use DDE to interoperate with TQSL - it directs Windows to start TQSL with a particular set of command line arguments, and then waits for TQSL to create a file containing the requested results ("news" about a new version or approaching Callsign Certificate expirations). With LoTW not available, TQSL never creates that file; DXKeeper eventually gives up.?

+ It's possible that DXKeeper waiting for that file to be created is responsible for the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior on some systems. What happened after you cleared the "TQSL.exe pathname"?

? ? ? 73,

? ? ? ? ? ? Dave, AA6YQ

On Sat, Jun 15, 2024 at 03:47 PM, Dave AA6YQ wrote:

clearing the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab eliminate the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior?

+ DXKeeper does not use DDE to interoperate with TQSL - it directs Windows to start TQSL with a particular set of command line arguments, and then waits for TQSL to create a file containing the requested results ("news" about a new version or approaching Callsign Certificate expirations). With LoTW not available, TQSL never creates that file; DXKeeper eventually gives up.?

+ It's possible that DXKeeper waiting for that file to be created is responsible for the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior on some systems. What happened after you cleared the "TQSL.exe pathname"?

Thanks for such a quick response, Dave.

My DXLab Suite and PF is currently without any hiccup, but I'm going to attempt to recreate the PF hiccup thusly:

1) I reinserted what I had removed weeks ago, the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and then proceeded to terminate DXLab Launcher and all enabled programs.
2) Restarted the PC.
3) DXLauncher opens all enabled programs.
4) DXKeeper opens and displays only a [CC] in it's titlebar and not what I would expect to see, [CC,PF].
5) A popup window, "DXKeeper: Updates from LoTW" reports, "TQSL is unable to connect LoTW". I acknowledge with an "OK" click and the popup closes.
6) I click on a previously logged entry in the DXKeeper log and focusing on the PF window I see no response there. What I expect to see is the selected callsign's QRZ page.
7) The hiccup has returned. PF will not respond to queries.
7) I close PF, relaunch PF, and now [CC,PF] is displayed on the DXKeeper titlebar.
8) PF works as it should for this session of DXLab Suite. With a reboot, the PF hiccup returns.

--------- Now, to return my system to not having the PF hiccup I follow these steps:

1) I remove the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and proceed to terminate DXLab Launcher and all enabled programs.
2) Restart the PC.
3) DXLauncher opens all enable programs.
4) DXKeeper opens and displays a [CC,PF] in the titlebar as it should for me.
5) There is no popup window warning of LoTW being offline or TQSL difficulties nor of any other potential problem
6) PF responds as it should and has for several weeks now, but only after eliminating the TQSL.exe pathname as cited above. My reasoning for erasing the TQSL.exe pathname? Why launch an executable that cannot work until the LoTW server is restored.

All I know is that this detail has worked for me and once LoTW is restored I'll reinsert the TQSL.exe pathname.

Dave, I have not seen the "on startup, DXKeeper isn't connected to Pathfinder" popup. I've been spared that one <whew!>

Oh, and thanks for the clarification about DDE calls and such. You're the program guru. I most certainly am not. (hi hi)
-Joe?

# More AA6YQ comments below

clearing the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab eliminate the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior?

+ DXKeeper does not use DDE to interoperate with TQSL - it directs Windows to start TQSL with a particular set of command line arguments, and then waits for TQSL to create a file containing the requested results ("news" about a new version or approaching Callsign Certificate expirations). With LoTW not available, TQSL never creates that file; DXKeeper eventually gives up.

+ It's possible that DXKeeper waiting for that file to be created is responsible for the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior on some systems. What happened after you cleared the "TQSL.exe pathname"?

Thanks for such a quick response, Dave.

My DXLab Suite and PF is currently without any hiccup, but I'm going to attempt to recreate the PF hiccup thusly:

1) I reinserted what I had removed weeks ago, the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and then proceeded to terminate DXLab Launcher and all enabled programs.
2) Restarted the PC.
3) DXLauncher opens all enabled programs.
4) DXKeeper opens and displays only a [CC] in it's titlebar and not what I would expect to see, [CC,PF].
5) A popup window, "DXKeeper: Updates from LoTW" reports, "TQSL is unable to connect LoTW". I acknowledge with an "OK" click and the popup closes.
6) I click on a previously logged entry in the DXKeeper log and focusing on the PF window I see no response there. What I expect to see is the selected callsign's QRZ page.
7) The hiccup has returned. PF will not respond to queries.
7) I close PF, relaunch PF, and now [CC,PF] is displayed on the DXKeeper titlebar.
8) PF works as it should for this session of DXLab Suite. With a reboot, the PF hiccup returns.

--------- Now, to return my system to not having the PF hiccup I follow these steps:

1) I remove the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and proceed to terminate DXLab Launcher and all enabled programs.
2) Restart the PC.
3) DXLauncher opens all enable programs.
4) DXKeeper opens and displays a [CC,PF] in the titlebar as it should for me.
5) There is no popup window warning of LoTW being offline or TQSL difficulties nor of any other potential problem
6) PF responds as it should and has for several weeks now, but only after eliminating the TQSL.exe pathname as cited above. My reasoning for erasing the TQSL.exe pathname? Why launch an executable that cannot work until the LoTW server is restored.

All I know is that this detail has worked for me and once LoTW is restored I'll reinsert the TQSL.exe pathname.

# Many thanks, Joe! Your methodical approach demonstrates that when DXKeeper is not "connected" to Pathfinder at startup, the root cause is likely DXKeeper waiting for TQSL to respond to its "report the LoTW news" query.

# Rather than temporarily clear the TQSL pathname as you report above, I suggest instead making this change in the pathname:

TQSL.exe => TQSL.exef

# This will prevent DXKeeper from directing TQSL to "report the LotW news", but make it easy to restore the correct TQSL pathname after LoTW is again accessible.

Dave, I have not seen the "on startup, DXKeeper isn't connected to Pathfinder" popup. I've been spared that one <whew!>

# There is no such popup; that's just my concise description of the misbehavior.

Oh, and thanks for the clarification about DDE calls and such. You're the program guru. I most certainly am not.

# Nor should you need to be.

73,

Dave, AA6YQ

Dave,

I have seen this same situation between DXKeeper and Spot Collector. Ever since I changed the TQSL file to exef as you recommended previously, the issue has not reappeared.

Bruce - K5WBM

With me the TQSL.exef dosent work, I wrote a script where PF is started first, and than all other programs, thats working fine for me
73 Alex, OE3JTB

I have seen this same situation between DXKeeper and Spot Collector. Ever since I changed the TQSL file to exef as you recommended previously, the issue has not reappeared.

+ Thanks for the report, Bruce.

Dave

On Wed, Jun 12, 2024 at 08:32 PM, Dave AA6YQ wrote:

+ The mechanism that DXLab applications employ to interoperate (DDE) is provided by Windows. Since this misbehavior began independently of a new DXKeeper or Pathfinder release, I can only speculate that some other change to? your operating environment is responsible.

Not at all there was a change at my operating system, hint with TSQL.exef is now working also here, seems to be a timing problem before
tnx 73 Alex, OE3JTB