View Issue Details

IDProjectCategoryView StatusLast Update
0002716Ham Radio DeluxeBugpublic2019-02-25 18:08
ReporterPD9FERAssigned ToK7ZCZ 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.873 
Summary0002716: Build 840 Logbook: QTH entry vanishes when manually editing an existing QSO
DescriptionWhen manually editing an existing record (that has an QTH entry) the QTH info vanishes.
Upon using the Next button an then Prev, the QTH is visible again.
Steps To ReproduceOpen logbook
Double click an existing contact
Note there is a blank QTH field
Press Next button
Press Prev button
Note the QTH field is now populated
Additional InformationTicket #875378
TagsNo tags attached.
Sub-ModuleQSO Window
Testing Beta Successful


has duplicate 0002787 closedK7ZCZ 5 - Closed w/o Action Does not record QTH data 
related to 0003196 closedK7ZCZ Ham Radio Deluxe Logbook QTH Column Issue 



2018-05-15 04:53


A.png (213,790 bytes)
A.png (213,790 bytes)
B.png (168,118 bytes)
B.png (168,118 bytes)


2018-05-15 08:39

viewer   ~0005049

As per request to verify I proceeded to follow the steps as outlined above. Once these steps were followed the QTH field is now populated.


2018-05-15 10:55

viewer   ~0005052

I get the same results as Ferry. This may be related to the Lookup as clicking on the Lookup button populates the empty QTH field.
Then click Update. Reload that QSO and the QTH is empty again.


2018-05-18 07:33

viewer   ~0005065

Someone else has reported this in the Forum.


2018-05-24 02:21

viewer   ~0005097

Also got noticed and can confirm the RST field is being reset during this procedure.
If I need to create an separate Mantis entry for that, let me know.


2018-05-24 03:21

viewer   ~0005098

The RST field is not being reset for me.


2018-05-24 03:43

viewer   ~0005099

I was not clear enough, it is the Contest exchange (next to the RST) being reset.


2018-05-31 01:11

viewer   ~0005156

A number of owners are reporting the QTH field being empty on loading a QSO into the ALE. I suggest this be given high priority.


2018-06-04 09:16

administrator   ~0005192

Last edited: 2018-06-04 09:17

View 2 revisions

I don't really think it has anything to do with "Prev/Next" particularly... but it could be. (I'm not sure "Prev/Next" is working the way it was intended. It was intended to move to the "Previous" or "Next" record in the database to eliminate the tiresome need of continually closing one to open the next.

That said... if the contents change when someone selects "Prev/Next", the user should probably get prompted about whether they want to change the record.

Back on point... we do need to make sure we fix this "QTH vanishing thing" as a priority.


2018-06-04 09:39

developer   ~0005193

It's not clear to me what's being reported here. Did the record that was opened have a value in the QTH field before it was opened in the first step? The scereen shot shows the Logbook list view, but that view doesn't include the QTH column. The instructions make no mention of the QTH field being initially populated or not.

I'm trying to figure out if this complaint is about a value existing in the database but not being shown when the record is first opened; or if the problem is actually that data is added to the QTH field without the user's explicit permission.


2018-06-04 10:47

viewer   ~0005195

I have created a video which shows what I see.

Vanishing (1,182,922 bytes)


2018-06-04 10:51


QTH (44,267,036 bytes)


2018-06-04 10:52

viewer   ~0005196

Sorry, I uploaded the wrong file, it should be MP4


2018-06-05 08:10

developer   ~0005199

Thanks UCQ. So, this has nothing to do with the record changing as PIE says; it's just that the QTH isn't populated into the ALE when the record is first opened.

Do I have it right?


2018-06-05 09:12

viewer   ~0005200

Yes, that is correct. The video shows that, despite Updating the QSO info, the QTH field is not saved. Also reported in the Peer to Peer Logbook forum by many.


2018-06-07 11:43

developer   ~0005215

This is a good example of something that appears simple to fix but is really quite complicated because of interdependent bad behaviours, and no good specification of the correct desired behaviour.

Windows code works by handling messages. An edit control receives a message when a user changes the text in it, for example. If I want to do something interesting in response to the user typing something into to he control, I handle the message the control sends. "Handle" just means write some code that's called when the messgae is sent; that code runs when the user performs the action that causes the message.

The Logbook ALE has a few fields that appear more than once in the UI. I assume that these fields are meant to be kept in sync; typing in one field updates the content of the other field immediately. There's no real reason why the fields would have to different values. The interesting duplicated fields in the context of this bug are the "QTH" field, which appears in the main window and on the "location" tab; and the "State" field, which appears on the main window and as "State/province" on the "Location" tab.

If we open an ALE and activate the "location" tab, we can type into either "QTH" field and see the keystrokes immediately update the other field. Same for the "State" field.

Demonstrating the linekd fields shows the intention that the fields are always kept in sync.

To implement the in-sync feature, code was written to react to changes to each control. When one of the edit controls is changed, the message handler notices that change and tells the other control that it should update its content. Thus, when the user types a character in one control, this code runs and copies the character to the other control.

That code, however, is naievely implemented. It turns out that any change to the control's text invokes the handler. When the window loads itself with new content from the logbook, that counts as a change even though the user isn't typing anything into the control directly. When the window wants to reset and clear itself, setting the edit control to empty also counts as a change.

The root cause of this bug is that the code to clear the content of the window and the code to load the content of the controls from a logbook record race eachother. We don't know which time the handler will be invoked first, and it's possible that the controls end up being inconsistent.

I don't think it's too hard to synchronize the controls so that they're only reflecting user input to eachother. When I test that fix, I discover that there is an elaborate mechanism of copying values from logbook records into an out of the ALE controls that might not be working correctly. For a reason unknown to me, some controls are (or are not) copied from the logbook record. Controls not copied are left untouched when the rest of the content is copied and populated.

It turns out that the State and QTH fields on the "Location" tab are among those that aren't copied at all. It turns out, then, that the QTH and State fields on the "Location" tab were only ever populated because they were trying to reflect eachother, even though they were deliberately not populated by the code which selects which fields to copy (or not).

There are two features here: one that synchronizes the two controls, and another that copies data selectively from logbook entries. These two features are dependent on bugs in the other.

In order to fix the issue of the field not populating, we need to decide if it should populate at all times; there's code that actively indicates that it shouldn't. There is code, on the other hand, that is at odds with that implementation and (sometimes successfully) causes the data to be copied.

What's the desired solution?


2018-06-07 16:11

viewer   ~0005227

Without checking earlier versions but using. 842 with the Logbook tab open in the ALE, clicking on a QSO in the Logbook of a callsign I have worked before, the Logbook is not populated with any previous QSOs. Clicking the Lookup button populates the empty QTH field and also adds the previous QSOs.


2018-06-19 08:45

developer   ~0005356

Nothing heard in response to my queries, so I'm shelving this partial fix in hopes that we will have answers and can resume work towards a fix.


2018-06-19 10:24

viewer   ~0005357

Sorry I do not access VS. This problem is causing considerable annoyance to users, see the peer forum. Prority fix please.


2018-06-25 20:11

developer   ~0005489

More aggressive fix here, built on the assumption that populating all fields is acceptable.


2018-06-26 13:16

administrator   ~0005491

Next and Previous was introduced as a method to enable users to view log records without having to close the ALE. "Next" should display the full contents of the next QSO (database record). "Previous" should display the full contents of the previous QSO (database record). This functionality was not designed to populate data into a different database record. If the user decides to edit a record before hitting Next/Previous, they should be prompted to "Save" the record before displaying a different database record. This is the way it was intended to work.


2018-06-26 13:17

administrator   ~0005492

Mike, I have sorted my logbook in Callsign Order, so I can show that all the QTH information is populated for the callsign I'm using to test with. I double right clicked on the first QSO with F2YT to open that contact in the Editor window. If you will look at QTHError (1).png, you will clearly see the QTH is populated in the Logbook, but it is NOT populated in the QTH field in the editor window.

After clicking the [NEXT] button on the bottom of the editor screen, the editor moved on to the NEXT QSO with F2YT, and it DID populate the QTH in the QTHError (2).png image I included. Again you can clearly see the QTH in ALL QSOs with F2YT is populated with exactly the same data.

There appears to be a problem when you click on double-left click on a contact to open it in the Editor window that prevents it from displaying the QTH the first time you open a call in the editor like this.

QTHError (1).png (148,963 bytes)
QTHError (1).png (148,963 bytes)
QTHError (2).png (157,443 bytes)
QTHError (2).png (157,443 bytes)


2018-06-29 16:53

developer   ~0005549

I've moved this fix to my private branch, which has a handful of other ALE fixes.


2018-07-09 11:55

administrator   ~0005642

I just added a video into the Dump folder showing the EXACT steps to produce the error in this ticket. There's no audio but I think it will demonstrate exactly what is happening. I don't believe this has anything to do with that other Mantis 2787.

Here is the link for the video I created:
Team Drives\HRD Software\Dumps\Mantis_0002716.wmv


2018-07-12 14:30

developer   ~0005657

merged to the main branch with this checkin:


2018-07-12 14:54

viewer   ~0005663

These URL's
We can't see/do anything with them....
A Fixed/can't Fix or whatever would be better...
This is confusing.


2018-07-12 16:41

developer   ~0005664

Just ignore the links to the change lists in the source code. They're for developers; we use them to track our work.


2018-07-13 15:17

viewer   ~0005674



2018-07-14 06:54

viewer   ~0005698


Issue History

Date Modified Username Field Change
2018-05-15 04:53 PD9FER New Issue
2018-05-15 04:53 PD9FER File Added: A.png
2018-05-15 04:53 PD9FER File Added: B.png
2018-05-15 08:39 KC7FPF Note Added: 0005049
2018-05-15 08:56 PD9FER Severity minor => tweak
2018-05-15 08:56 PD9FER Description Updated View Revisions
2018-05-15 08:56 PD9FER Steps to Reproduce Updated View Revisions
2018-05-15 08:56 PD9FER Additional Information Updated View Revisions
2018-05-15 08:56 PD9FER Testing => Not Started
2018-05-15 10:55 g3ucq Note Added: 0005052
2018-05-18 07:33 g3ucq Note Added: 0005065
2018-05-24 02:21 PD9FER Note Added: 0005097
2018-05-24 03:21 g3ucq Note Added: 0005098
2018-05-24 03:43 PD9FER Note Added: 0005099
2018-05-31 01:11 g3ucq Note Added: 0005156
2018-06-04 09:16 WA9PIE Note Added: 0005192
2018-06-04 09:16 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2018-06-04 09:17 WA9PIE Note Edited: 0005192 View Revisions
2018-06-04 09:39 K7ZCZ Note Added: 0005193
2018-06-04 10:47 g3ucq File Added: Vanishing
2018-06-04 10:47 g3ucq Note Added: 0005195
2018-06-04 10:52 g3ucq File Added: QTH
2018-06-04 10:52 g3ucq Note Added: 0005196
2018-06-05 08:10 K7ZCZ Note Added: 0005199
2018-06-05 09:12 g3ucq Note Added: 0005200
2018-06-06 08:33 WA9PIE Assigned To => K7ZCZ
2018-06-06 08:33 WA9PIE Status new => assigned
2018-06-07 11:43 K7ZCZ Note Added: 0005215
2018-06-07 16:11 g3ucq Note Added: 0005227
2018-06-19 08:45 K7ZCZ Note Added: 0005356
2018-06-19 10:24 g3ucq Note Added: 0005357
2018-06-23 17:09 WA9PIE Severity tweak => major
2018-06-25 20:11 K7ZCZ Note Added: 0005489
2018-06-26 13:16 WA9PIE Note Added: 0005491
2018-06-26 13:17 KB3NPH File Added: QTHError (1).png
2018-06-26 13:17 KB3NPH File Added: QTHError (2).png
2018-06-26 13:17 KB3NPH Note Added: 0005492
2018-06-29 16:53 K7ZCZ Note Added: 0005549
2018-07-06 22:46 K7ZCZ Relationship added has duplicate 0002787
2018-07-09 11:55 KB3NPH Note Added: 0005642
2018-07-12 14:30 K7ZCZ Status assigned => resolved
2018-07-12 14:30 K7ZCZ Resolution open => fixed
2018-07-12 14:30 K7ZCZ Fixed in Version =>
2018-07-12 14:30 K7ZCZ Note Added: 0005657
2018-07-12 14:54 PD9FER Note Added: 0005663
2018-07-12 16:41 K7ZCZ Note Added: 0005664
2018-07-13 15:17 g3ucq Note Added: 0005674
2018-07-14 06:54 PD9FER Note Added: 0005698
2018-07-17 16:51 WA9PIE Status resolved => closed
2018-07-17 16:51 WA9PIE Testing Not Started => Beta Successful
2018-07-23 22:52 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2018-07-24 15:36 WA9PIE Project Ham Radio Deluxe => 3 - Current Dev List
2018-07-25 08:00 WA9PIE Fixed in Version =>
2018-07-25 20:47 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2019-02-25 18:08 K7ZCZ Relationship added related to 0003196