View Issue Details

IDProjectCategoryView StatusLast Update
0002822Ham Radio DeluxeBugpublic2019-03-06 20:06
Reporterg3ucqAssigned ToK7ZCZ 
Status closedResolutionduplicate 
PlatformPCOSWindowsOS Version10 64 bit Home
Product Version 
Target VersionFixed in Version6.4.0.876 
Summary0002822: Logbook not saving USA State data
DescriptionOpen the Logbook ALE and enter a USA callsign.
The State is not saved when the ALE is closed.
Steps To ReproduceThese steps to replicate were tested on my system (Tim (KB3NPH)) while Mike C was connected via TeamViewer in order to verify the process.

Open Logbook and on main menu click "Tools > Configure > Callsign Lookup" and set the lookup order to:
1. Subscription
2. Logbook
3. Country List
Then click the [Apply] followed by [OK]

Entry procedure:
1. Click [Add] icon to open the ALE
2. IMPORTANT STEP: Check the TABS that are across the ALE screen that are about 2/3 of the way down the page and make sure the "LOGBOOK" tab is selected.
3. Enter a USA callsign in the "Call" field and either click the "TAB" key on your keyboard or click the [Lookup] button on the ALE GUI.
4. After the lookup you will note the "State" field is populated with the proper state ID.
5. Click the [Add (f7)] button to save the QSO to the Logbook. Check the saved record and you will see the State ID is not populated in the logbook record.

BE SURE TO DO THIS NEXT PROCEDURE ALSO. It may give an idea of exactly where the problem is.
1. Open the ALE by clicking the [Add] icon
2. For this test select and open the "Location" tab in the TABS on the ALE screen about 2/3 of the way down the page.
3. Enter a USA callsign in the "Call" field as did in the first procedure.
4. Click the "TAB" key on your keyboard or click the [Lookup] button on the ALE GUI to initiate the lookup.
5. Note that the lookup process populated both the normal "State" field in the upper part of the screen and also the "State" field in the "Location" tab display.
6. Click the [Add (F7)] button on the GUI to save the contact to the logbook.
7. Check the record saved in the logbook from this test and notice the State ID HAS been saved in the record as it should be.

This procedure demonstrates the State is NOT saved if the "Logbook" tab is selected and the State IS SAVED if the "Location" tab is select. Most customers have the "Logbook" tab selected by default since they can see in the Status window any/all previous contact records with the call entered in the "Call" field of the ALE.

Additional InformationAs posted by one user.

When you open a previous entry with the state field blank, if your ALE window has the LOCATION tab selected, you can do another lookup from and then save the change and the State field WILL be saved. If you did not select the LOCATION tab then it WON'T be saved.

The same is true for a new lookup, if you have the Location tab selected, the state WILL be saved, if you don't, it WON'T.
TagsNo tags attached.
Sub-ModuleALE Window
Testing Beta Successful


duplicate of 0002824 closedK7ZCZ Contact's "STATE" not logging in V6.4.0.873 



2018-08-01 10:15

administrator   ~0005898

As far as I can tell, this is a duplicate of 2824. 2822 was opened first, but 2824 has a bit more detail in the repro case so let's start with that one.


2018-08-01 13:41

viewer   ~0005900

Yes, it is a duplicate of 2822 so that can be deleted.


2018-08-04 00:19

administrator   ~0005915

As I mentioned in 2824, this is a much better repro case than 2824. Tim and I went step-by-step in writing the steps for this (2822). I had the expectation that these steps would replace the ones in 2824.

Regardless, let's leave them both open until we fix this. We now have a number of people complaining.

The work-around for this (from a user perspective), is to make the Location tab the active (in-focus) tab while saving a QSO.


2018-08-04 21:39

administrator   ~0005937

This was a much worse descriptoin of the problem before it was re-written, of course.

Since the issues are the same, I can't understand the point of having both activate. But today's checkin should resolve both, as well.


2018-08-04 21:39

administrator   ~0005938

I think this is fixed with this checkin:

Issue History

Date Modified Username Field Change
2018-07-31 04:54 g3ucq New Issue
2018-08-01 10:15 K7ZCZ Assigned To => K7ZCZ
2018-08-01 10:15 K7ZCZ Status new => resolved
2018-08-01 10:15 K7ZCZ Resolution open => fixed
2018-08-01 10:15 K7ZCZ Note Added: 0005898
2018-08-01 10:15 K7ZCZ Relationship added duplicate of 0002824
2018-08-01 13:41 g3ucq Note Added: 0005900
2018-08-03 22:58 KB3NPH Steps to Reproduce Updated View Revisions
2018-08-03 22:59 KB3NPH Steps to Reproduce Updated View Revisions
2018-08-04 00:19 WA9PIE Status resolved => assigned
2018-08-04 00:19 WA9PIE Resolution fixed => open
2018-08-04 00:19 WA9PIE Note Added: 0005915
2018-08-04 21:39 K7ZCZ Note Added: 0005937
2018-08-04 21:39 K7ZCZ Status assigned => resolved
2018-08-04 21:39 K7ZCZ Resolution open => duplicate
2018-08-04 21:39 K7ZCZ Note Added: 0005938
2018-08-08 18:20 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-08-08 18:21 K7ZCZ Fixed in Version =>
2018-08-09 23:03 WA9PIE Status resolved => closed
2018-08-09 23:03 WA9PIE Testing Not Started => Beta Successful
2018-08-09 23:03 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2019-03-06 20:06 WA9PIE Fixed in Version =>