View Issue Details

IDProjectCategoryView StatusLast Update
0003196Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterKC7FPFAssigned ToK7ZCZ 
Status closedResolutionunable to reproduce 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0003196: Logbook QTH Column Issue
DescriptionWhen adding an entry using the "ADD" function the following issue occurs. While the QTH field does have data in it, when you click ADD to add the entry to your logbook, the QTH Column in your logbook is blank. If you try and edit the entry the QTH field in the MODIFY window is blank. So you do a lookup and the field fills in, but when you click UPDATE to update the log entry, the QTH Column in the logbook is still blank.

Now if a is made contact using WSJT-X and have it log directly into HRD the QTH Column in the logbook is filled in and I can even edit the entry without any issues. But using the regular ADD window has the issues shown above.
Steps To ReproduceOpen Logbook.
Open the Add button
Enter a call sign to look up
Look up option works fine auto fills the fields as required.
Go to add contact all information is saved except the QTH field.

Same is true when you attempt to edit the contact. all information is saved except the QTH information.

Via Ticket 211719
Additional InformationTested and confirmed by Ferry Tim and Kevin.
TagsNo tags attached.
Sub-ModuleCall lookup
Testing Beta Successful


related to 0002716 closedK7ZCZ Build 840 Logbook: QTH entry vanishes when manually editing an existing QSO 
related to 0003001 closedWA9PIE Callsign lookup function does not appear to be working as designed 



2019-02-25 18:17

developer   ~0007506

Last time we noticed this symptom, it was caused by a race in messages between different location controls in the ALE. That's described in 2716.

The implementation of the ALE window is a house of cards, based on two or three different code paths that pass unsynchronized Windows messages to eachother. 2716 documents this specifically for the QTH and location tab, and 3192 discusses the issue more generally.

We've considered a stop-gap fix for 3192, but I think that a more aggressive solution might be appropriate. We could also try to make a reactive, isolated solution for this specific issue. Since we're fighitng multiple issues in the same section of the application, I think isolated fixes are the wrong way to go because they end up patching the issue and are in the long-term destabilizing.

Re-writing the ALE would help eliminate the race coniditons and the complexity in the implementation. Eliminating the race would elimnate this class of bugs ... helping the complexity would help avoid such bugs in the future, and make the code more maintainable.

Re-implementing the code without a clear specification of how it's meant to work is shooting at a moving, undefined target. 3001 seems to be the best issue we have to track the wrok of building a speicfication for this part of the product.


2019-02-26 17:32

developer   ~0007509

We decide to fix this promptly, but not compeltely. This checkin does a conservative fix:


2019-02-27 22:18

developer   ~0007529

I'm compelled to document that I'm not able to reproduce this issue as it is described.

If I open the ALE and lookup a callsign, the lookup doesn't populate the ALE, for sure. That's what I fixed.

If I manually enter something into the ALE field and save the entry, it saves correctly. If I load the entry, the value in the QTH field is presented to me. This issue describes a bi-directional data movement problem between the logbook view window and the ALE, and I'm not able to reproduce that issue.


2019-10-25 03:28

developer   ~0009011

I've never really been able to repro this. I just tried again with build, and no luck there, either.


2019-10-29 05:28

administrator   ~0009063

While it wasn't possible to reproduce this, we did validate that the QTH field is populated via all callsign lookup sources.

Issue History

Date Modified Username Field Change
2019-02-25 12:45 KC7FPF New Issue
2019-02-25 12:45 KC7FPF Status new => assigned
2019-02-25 12:45 KC7FPF Assigned To => K7ZCZ
2019-02-25 14:05 WA9PIE Description Updated View Revisions
2019-02-25 14:55 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2019-02-25 18:08 K7ZCZ Relationship added related to 0002716
2019-02-25 18:17 K7ZCZ Note Added: 0007506
2019-02-25 18:17 K7ZCZ Relationship added related to 0003001
2019-02-26 17:32 K7ZCZ Note Added: 0007509
2019-02-27 22:18 K7ZCZ Note Added: 0007529
2019-03-02 00:25 WA9PIE Status assigned => acknowledged
2019-10-25 03:28 K7ZCZ Status acknowledged => resolved
2019-10-25 03:28 K7ZCZ Resolution open => unable to reproduce
2019-10-25 03:28 K7ZCZ Note Added: 0009011
2019-10-29 05:28 WA9PIE Status resolved => closed
2019-10-29 05:28 WA9PIE Fixed in Version =>
2019-10-29 05:28 WA9PIE Sub-Module (select) => Call lookup
2019-10-29 05:28 WA9PIE Testing N/A => Beta Successful
2019-10-29 05:28 WA9PIE Note Added: 0009063
2019-11-08 02:10 WA9PIE Fixed in Version =>
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe