Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- DXLab
- Messages
Search
|
Problem creating DXKeeper User Field
After a catastrophic computer failure, I'm now reconstructing DXLab after reinstalling Win 11. Prior to the crash, I had two user fields with drop down choices in DXKeeper. I'm trying to re-create them and can't seem to get them to work. I created a list for each one and saved them in Notepad txt files. I then went to User Items in the DXK config window and clicked on the Set List button with Style set to List. The expected window opened and I saw my text files. When I opened them and clicked on the Load button, I expected to see the drop downs in each field in the log window, but both fields remained blank. I must have done (or not done) something, but I don't see what went wrong. Can someone help? Thanks.
Jeff, K6JW |
|
Re: Clearing QSL Queue
Thanks Joe, I did enable, un-enable and re-enable and see if things changed.
toggle quoted message
Show quoted text
But no joy. vy 73, Dave, w0rx On 1/22/2025 5:26 PM, Joe Subich, W4TV wrote:
I don't remember having to go back to the log and updating each sentDid you, perhaps, uncheck the "QSL" box as you printed labels, or |
|
Re: Clearing QSL Queue
I don't remember having to go back to the log and updating each sentDid you, perhaps, uncheck the "QSL" box as you printed labels, or addresses, etc.? If so, click "enable all" before clicking "Update Log" ... 73, ... Joe, W4TV On 2025-01-22 5:48 PM, w0rx - David Willis via groups.io wrote: I finished processing a batch of QSL cards from the bureau.? After printing the labels, 3 col stick-ons, I pressed the "update log" button whose tooltip says: for each printed QSL label, update the QSOs QSL sent status to yes and its QSL sent date to now and delete the QSL queue entry.? However, the QSL queue list remains.? I can clear it with the clear button. However, then pressing "add requested" brings the same list back. Also there is no QSL sent date in the log entries selected for QSLing. |
|
Re: Clearing QSL Queue
+ AA6YQ comments below
I finished processing a batch of QSL cards from the bureau. After printing the labels, 3 col stick-ons, I pressed the "update log" button whose tooltip says: for each printed QSL label, update the QSOs QSL sent status to yes and its QSL sent date to now and delete the QSL queue entry. However, the QSL queue list remains. I can clear it with the clear button. However, then pressing "add requested" brings the same list back. Also there is no QSL sent date in the log entries selected for QSLing. + So that I can see what's going on, please do the following: 1. on the Configuration window's General tab, check the "Log debugging info" box 2. terminate DXKeeper 3. start DXKeeper 4. load your printer with some cheap paper 5. assuming that the "QSL Via" panel is still set to 3-column labels and the QSL Queue is still populated, on the Main window's QSL tab, 5a uncheck the "Print preview" box 5b. click the "Print QSL Labels" button 5c. click the "Update log" button 6. on the Configuration window's General tab, uncheck the "Log debugging info" box 7. attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me via aa6yq (at) ambersoft.com 73, Dave, AA6YQ |
|
Clearing QSL Queue
I finished processing a batch of QSL cards from the bureau.? After printing the labels, 3 col stick-ons, I pressed the "update log" button whose tooltip says: for each printed QSL label, update the QSOs QSL sent status to yes and its QSL sent date to now and delete the QSL queue entry.? However, the QSL queue list remains.? I can clear it with the clear button. However, then pressing "add requested" brings the same list back. Also there is no QSL sent date in the log entries selected for QSLing.
I don't remember having to go back to the log and updating each sent QSL.? What am I doing wrong? Tnx and vy 73, Dave, w0rx |
|
Re: Spotcollector call information popup box
Tnx Dave for the details. My problem was I was clicking for ssb/cw and it would work but not for ft8/4 which now makes sense. It is a very useful tool to stay away from dupes and of course, jt alert will show you if it's a B4 or new contact. OK....I'm covered. tnx again for your time Dave and you still haven't told us how you can get 30 hrs out of a 24 hr day to do what you do.
I think too when we thank you for your guidance, we should be thanking your other half for sharing you with the ham community
Ron K3LUE 73 |
|
Re: On posting problem reports
+ AA6YQ comments below
I read this in the documentation: "Unless you've checked an application's Log Debugging Info box, it should never produce an errorlog.txt file. If it does,..." I was doing some housekeeping and getting rid of some old error logs in each application. Since none were recent (dated last year), I deleted them, so each application did not have an error log. I then terminated all applications, and restarted them. (DXLab apps). When I examined each app (DXLab), there was a new errorlog.txt file in DXKeeper: Contents of ErrorLog.txt : 2025-01-22 20:09:07.680 > Common.Terminate: DXKeeper shutdown + That means DXKeeper had added one or more entries to its Errorlog.txt file - which you deleted. 73, Dave, AA6YQ |
|
Re: On posting problem reports
Dave, I read this in the documentation: "Unless you've checked an application's Log Debugging Info box, it should never produce an errorlog.txt file. If it does,..." I was doing some housekeeping and getting rid of some old error logs in each application. Since none were recent (dated last year), I deleted them, so each application?did not have an error log. I then terminated all applications, and restarted them. (DXLab apps). When I examined each app (DXLab), there was a new errorlog.txt file in DXKeeper: Contents of ErrorLog.txt : 2025-01-22 20:09:07.680 > Common.Terminate: DXKeeper shutdown ...seems harmless enough, but it seems to violate the injunction that unless I have an app's?Log Debugging Info box, it should never produce an errorlog.txt file.? (I checked and none of the apps have the?box checked) Not a big deal, but I thought I'd report it as an inconsistency. 73, N0AN Hasan On Wed, Jan 22, 2025 at 1:56?PM Dave AA6YQ via <aa6yq=[email protected]> wrote: + AA6YQ comments below |
|
Re: Updating Logged QSOs to Reflect Status Downloaded from IOTA
# More AA6YQ comments below
snip< that's why DXpeditioners to rare DXCC entities must arrange for someone to work them from their home station.Or they could use their satellite connection to work the rare island from their home station a few times while cooling their heels on the boat offshore, like several members of the last Bouvet operation supposedly did ?? # As Dave K1ZZ quipped, "it's just a long microphone cord". 73, Dave, AA6YQ |
|
Re: Updating Logged QSOs to Reflect Status Downloaded from IOTA
+ If activating an IOTA island gives you IOTA credit for working and confirming that island, then I suggest that you log a QSO with yourself on the correct band and mode with the QSO time as specified in the .csv file you downloaded from IOTA.I only activated US islands in FL, AL, and GA this year, so the DXCC confirmation wouldn¡¯t be an issue in this case. So, I¡¯ll take your suggestion, and worry about the rare one when/if I activate it. that's why DXpeditioners to rare DXCC entities must arrange for someone to work them from their home station.Or they could use their satellite connection to work the rare island from their home station a few times while cooling their heels on the boat offshore, like several members of the last Bouvet operation supposedly did¡ ? Thanks for your help! |
|
Re: On posting problem reports
+ AA6YQ comments below
Instructions would be more consistent if the "log debugging info" check boxes were retitled "error log". You instructions and commentary refer often to "error log", but one has to search and read to find out that the box to be checked is not labeled "error log" but "log debugging info". + When a DXLab application detects a program error, it records relevant information in entries in a file named errorlog.txt in its folder, and displays the message See <application name> Errorlog.txt + in its Main window's title bar. That's a cue for the user who doesn't know what that means to either post a message here, or search + for the word errorlog, which will locate this article: + Errorlog.txt files generated in this manner always include the phrase "program error". + A "Log debugging information" option is provided on the General tab of each DXLab application's Configuration window so that when necessary, I can obtain detailed information about a situation reported by a user. When this is the case, I always 1. ask the user to enable the "Log debugging information" option on the application's Configuration window's General tab 2. specify a set of actions to take, or an event to await 3. ask the user to disable the "Log debugging information" option + There is no situation in which the user must search for the name of the option to enable. Thus there is no need to change the name of this option. Should one normally operate with the "log debugging info" box for any or all applications checked (and active)? + Users should never enable "Log debugging information" in the absence of my request, as the resulting errorlog.txt file will typically be useless because I can't correlate its contents with higher-level application behavior. + Errorlog.txt files are not intended for consumption by users. That's why their contents are not documented. 73, Dave, AA6YQ |
|
Re: Bonaire, Kalingrad & European Russia
It's clear that the root cause of the reported problems is erroneous DXCC information in QRZ callbook entries.
Since you can't modify another station's QRZ callbook entry, the corrective action is to define an override in DXView: Note that populating DXView's Override list from AD1C or Club Log will increase the probability that incorrect callbook information won't be logged. You can populate DXView's Override list from both AD1C or Club Log; in the case of a conflict between the two, the source you populated second will prevail. 73, Dave, AA6YQ |
|
Re: Updating Logged QSOs to Reflect Status Downloaded from IOTA
+ AA6YQ comments below
The IOTA report came back with the 'not found in log' indications. Some were easy to adjust, like KL7/call in the report and call/KL7 in my log. Ditto with just the call versus call/6. VS6BG I can't explain; the call and data is the same in both the IOTA report and my log. + The reported QSO time must be within 15 minutes before or after the logged QSO time. The five IOTA activations I did that I got credit for show my call as the worked station, and of course, my call is not in the log. In order to qualify for credit, IOTA wanted me to send my IOTA card with the first QSO from the activation. I could show the first station I worked from each activation as being on the island; I'm not sure what all the repercussions of that might be. Or, I could try to insert my call as if I worked myself from the island, but that would be weird. I wonder how others have addressed that? + If activating an IOTA island gives you IOTA credit for working and confirming that island, then I suggest that you log a QSO with yourself on the correct band and mode with the QSO time as specified in the .csv file you downloaded from IOTA. However, this would not qualify you for a DXCC confirmation with the island's DXCC entity; that's why DXpeditioners to rare DXCC entities must arrange for someone to work them from their home station. 73, Dave, AA6YQ |
|
Re: Bonaire, Kalingrad & European Russia
+ AA6YQ comments below
If the data is user-supplied and the QRZ webpage shows the correct data such as the case with R2FC and PJ4JA I don¡¯t understand where else they are getting the user-supplied data? + What the QRZ web page shows today is irrelevant. + What's relevant is what the QRZ web page showed on the day that the QSO was logged. 73, Dave, AA6YQ |
|
Re: Spotcollector, connection timed out but still GREEN
+ AA6YQ comments below
I have one (out of three) spot sources that regularly times out, but the indicator remains green in the spot source status tab......when I open that source window, it says connections timed out.....why does the indicator remain green? + Evidently, Windows is not reporting the timeout until you take some action, despite the fact that SpotCollector sends a <13><10> to each connected cluster every 30 minutes as a "keep alive". + I've added diagnostics to the next version of SpotCollector that should shed more light on what's going on. 73, Dave, AA6YQ |
|
Re: Bonaire, Kalingrad & European Russia
Thanks, Joe, for setting me straight and teaching me something new. I did not know the flag was used to determine the country, nor did I know you could click on the flag and change it.
toggle quoted message
Show quoted text
Tom-KQ5S On Jan 22, 2025, at 12:47, Joe Subich, W4TV via groups.io <lists@...> wrote: --
Tom-KQ5S |
|
Re: Updating Logged QSOs to Reflect Status Downloaded from IOTA
The IOTA report came back with the ¡°not found in log¡± indications. Some were easy to adjust, like KL7/call in the report and call/KL7 in my log. Ditto with just the call versus call/6. VS6BG I can¡¯t explain; the call and data is the same in both the IOTA report and my log.
toggle quoted message
Show quoted text
The five IOTA activations I did that I got credit for show my call as the worked station, and of course, my call is not in the log. In order to qualify for credit, IOTA wanted me to send my IOTA card with the first QSO from the activation. I could show the first station I worked from each activation as being on the island; I¡¯m not sure what all the repercussions of that might be. Or, I could try to insert my call as if I worked myself from the island, but that would be weird. I wonder how others have addressed that? 73, Steve K4WA On Jan 22, 2025, at 12:35?PM, Dave AA6YQ <aa6yq@...> wrote: |
|
Re: Bonaire, Kalingrad & European Russia
QRZ *DOES NOT SHOW THE CORRECT DATA*
toggle quoted message
Show quoted text
Look up PJ4JA and look closely at the flag and country beside the callsign ... it shows Curacao! JA3AVO who "manages" that entry has entered the wrong country in the data ("DXCC Land" field). Similarly, look up R2FC and notice "Russia" to the right of the callsign. R2FC has entered his "country" rather than the correct "DXCC Land" in his data. 73, ... Joe, W4TV On 2025-01-22 1:27 PM, TOM-KQ5S via groups.io wrote:
If the data is user-supplied and the QRZ webpage shows the correct data such as the case with R2FC and PJ4JA I don¡¯t understand where else they are getting the user-supplied data? |
|
Re: Updating Logged QSOs to Reflect Status Downloaded from IOTA
+ AA6YQ comments below
Thanks Dave, I was on 17.9.7, but updated to the latest and that fixed it. I have nine ¡°not found in log(s)¡± I have to figure out, but five of those are my call from IOTAs I activated and received credit. Not sure how I should handle those, and hopefully the other four will be easy to resolve. + What action did you take that resulted in the "not found in log" reports? 73, Dave, AA6YQ |
|
Re: Bonaire, Kalingrad & European Russia
¿ªÔÆÌåÓýIf the data is user-supplied and the QRZ webpage shows the correct data such as the case with R2FC and PJ4JA I don¡¯t understand where else they are getting the user-supplied data? Tom - KQ5S
--
Tom-KQ5S |
Ron T
to navigate to use esc to dismiss