View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003196||3 - Current Dev List||Bug||public||2019-02-25 12:45||2019-03-02 00:25|
|Target Version||Fixed in Version|
|Summary||0003196: Logbook QTH Column Issue|
|Description||When 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 Reproduce||Open 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 Information||Tested and confirmed by Ferry Tim and Kevin.|
|Tags||No tags attached.|
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.
We decide to fix this promptly, but not compeltely. This checkin does a conservative fix:
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-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|