View Issue Details

IDProjectCategoryView StatusLast Update
00030013 - Current Dev ListEnhancementpublic2019-10-13 09:15
ReporterWA9PIEAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionreopened 
Product Version6.5.0.157 
Target VersionFixed in Version6.7.0.226 
Summary0003001: Callsign lookup function does not appear to be working as designed
DescriptionWe have a user who reports that fields for new log entries for calls that are already in their log are not filled from the Logbook (Logbook being selected as an "Enabled Method" in the Callsign Lookup dialog box.
Steps To Reproduce- make sure that the only Enabled Methods in the Callsign Lookup dialog box are Logbook and Country List (and in that order)
- open the ALE and put a call in the callsign field
- invoke the callsign lookup function with either tab or pushing the "Lookup" button (this won't do much because the enabled methods won't turn up anything)
- populate a good number of the fields in the QSO record; save that record

Then create another log entry:
- open the ALE and put a call in the callsign field
- invoke the callsign lookup function with either tab or pushing the "Lookup" button (this won't do much because the enabled methods won't turn up anything)
- notice that none of the fields are filled by the Enabled Method (the Logbook)
Additional InformationThe attached document describes the intended design of the Callsign Lookup function wherever it is used.
TagsParityGap
ModuleLogbook
Sub-ModuleCall lookup
TestingNot Started

Relationships

related to 0003125 acknowledgedWA9PIE 1 - Backlog QSOs with stations that aren't in a valid DXCC country show up in the awards totals for a country and should not 
parent of 0003462 resolvedK7ZCZ 3 - Current Dev List call sign lookup options should always list Unique Call sign Database first 
parent of 0003463 resolvedK7ZCZ 3 - Current Dev List "Logfile" button in call sign lookup testing page is always disabled 
parent of 0003484 resolvedK7ZCZ 3 - Current Dev List Call sign lookup not working correctly or will freeze Logbook 
parent of 0003492 resolvedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the Country List method 
parent of 0003493 assignedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the QRZCQ method 
parent of 0003495 feedbackWA9PIE 3 - Current Dev List Complete the Callsign Lookup function for the Callook.info method 
parent of 0003496 resolvedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the QRZ.com Subscription method 
parent of 0003497 assignedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the Logbook method 
parent of 0003498 resolvedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the UCSDB (Public) method 
parent of 0003499 resolvedK7ZCZ 3 - Current Dev List Complete the Callsign Lookup function for the UCSDB (Private) method 
related to 0003015 closedK7ZCZ Ham Radio Deluxe Logobook ALE lookup code is overrun by copy-and-paste 
related to 0003047 closedK7ZCZ Ham Radio Deluxe move "Test" feature of Logbook's Callsign Lookup config to its own property page 
related to 0003046 closedK7ZCZ Ham Radio Deluxe move controls for the config of each Logbook Callsign Lookup data source their own property page 
related to 0003049 closedK7ZCZ Ham Radio Deluxe V6.4.0.907 - ALE showing Double City in fields 
related to 0003130 closedPD9FER 5 - Closed w/o Action Logbook ALE lookup disregards position set in Callsign Lookup order 
related to 0003135 closedK7ZCZ Ham Radio Deluxe Logbook's MessageDate() function isn't useful 
related to 0003145 closedK7ZCZ Ham Radio Deluxe Enhance logging output of callsign lookup feature 
related to 0003147 closedK7ZCZ Ham Radio Deluxe Logbook callsign lookup data source doesn't return much data 
related to 0002262 acknowledgedWA9PIE 1 - Backlog Add bulk callsign lookup in Logbook 
related to 0003196 acknowledgedK7ZCZ 3 - Current Dev List Logbook QTH Column Issue 
related to 0001395 acknowledged 1 - Backlog Automatically calculate location 
related to 0003192 acknowledgedWA9PIE 3 - Current Dev List Lat/Long, direction, and distance are incorrect in the Logbook ALE; "Log Coordinates" has opposite affect 
related to 0003187 resolvedWA9PIE 3 - Current Dev List V6.5.0.187 to 6.5.0.190 has problems with the Callsign Lookup Pane in the Logbook. 
related to 0001660 acknowledgedWA9PIE 1 - Backlog Use Maidenhead locator (grid square) for ALE coordinates 
related to 0000472 acknowledgedWA9PIE 1 - Backlog Add QRZ.com photo download into contact & option to show on ALE 
related to 0002006 acknowledgedWA9PIE 1 - Backlog Unify ALE into a single window for Logbook and DM780. Add a pictorial compact QRZ page within the larger unified ALE window 
related to 0001554 acknowledged 1 - Backlog Add function to use Callsign lookup on log import or initiate full log update 
related to 0002883 new 1 - Backlog Calbook (qrz.com) should not override UDP API supplied value for grid 
related to 0003284 closedK7ZCZ 3 - Current Dev List remove support for QRZ CD lookup 
related to 0002909 closedK7ZCZ 5 - Closed w/o Action Logbook: remove support for SAM Callsign CD lookups 
related to 0003376 feedbackKC7FPF 3 - Current Dev List Incorrect QTH Data 
related to 0002682 assignedKB3NPH 1 - Backlog DM-780 ALE not resolving Country in same manner as Logbook ALE 
related to 0003065 closedWA9PIE 3 - Current Dev List Add all fields to the Callsign Lookup function's Test tab 
related to 0003432 closedPD9FER 3 - Current Dev List When doing lookups with same station worked before, RST is set to latest QSO RST 
related to 0003305 closedPD9FER 3 - Current Dev List Logbook crashes on Callsign Lookup 
related to 0003464 resolvedK7ZCZ 3 - Current Dev List Some fields missing from QRZ.com call sign lookup 
Not all the children of this issue are yet resolved or closed.

Activities

WA9PIE

2018-12-18 11:52

administrator  

Callsign Lookup.docx (281,495 bytes)

K7ZCZ

2018-12-18 15:23

administrator   ~0006703

Is this issue about fixing the specific problem that customer reports, or is it about implementing the attached specification in its entirety?

WA9PIE

2018-12-20 12:05

administrator   ~0006735

In answer to your question...

I'm not sure if it's possible to fix the specific problem the customer reported without checking the whole entire callsign lookup function. If I were able to read the code, I suppose I'd know whether it's the entire callsign lookup function that wasn't done correctly... or if it's just this one lookup method.

At some point, we do need to finish it to its intended design. I would look for guidance from a developer who has looked at the code.

I'm going to run through some additional tests with other lookup sources and see how that goes.

K7ZCZ

2018-12-27 18:32

administrator   ~0006818

A bit of code cleanup with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4650

K7ZCZ

2018-12-31 11:30

administrator   ~0006829

Mantis 3015 cleans up the ALE lookup implementation significantly. More work to do, but this helps it become approachable.

K7ZCZ

2019-05-30 16:51

administrator   ~0007958

Switched to "enhnacement" per the team call on 2019-05-30

WA9PIE

2019-06-16 17:13

administrator   ~0008103

Any more specific questions? I don't see this happening until after the first 6.7 release.

K7ZCZ

2019-06-16 23:25

administrator   ~0008114

Not at the moment. I had made significant progress, but this work was set aside to work on the waterfall, which was set aside to work on the QLM code.

Dunno when I'll have the opportunity to get back to it.

K7ZCZ

2019-08-14 14:38

administrator   ~0008407

The first pass at this work is checked in. I guess I'm not quite ready to resolve this issue, but the feature could be tested in the 6.7 builds.

https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5122

K7ZCZ

2019-08-23 16:01

administrator   ~0008432

Another pass gets the reusable code hooked up to the Lookup pane and the Test dialog. Great shape, tho there's lots of cleanup and testing to di.

https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5125

K7ZCZ

2019-08-26 11:18

administrator   ~0008443

This hooks up the new code to DM780 via the IPListener interface
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5131

K7ZCZ

2019-08-26 11:52

administrator   ~0008444

removal /cleanup of old implementation:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5133
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5134

K7ZCZ

2019-08-26 13:40

administrator   ~0008445

more cleanup, hook up UDP Listener:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5135

K7ZCZ

2019-08-26 14:09

administrator   ~0008446

This checkin removes more old code, including the HRDLogbookCallsignLookup DLL.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5137

K7ZCZ

2019-08-26 14:13

administrator   ~0008447

I think this is ready to test. Between the issues getting the spec together and the multiple uses of this code, there are probably some bugs.

Testing should cover:

The Lookup Pane in the Logbook
the ALE in the Logbook
The QSO entry pane(s) in DM780
The UDP listener

and probably more ...


K7ZCZ

2019-08-27 10:08

administrator   ~0008453

Removes a few more obsolete definitions from the code:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5138

g3ucq

2019-09-02 08:07

updater   ~0008492

The Lookup is adding data from the previous ALE entry. F4 does not clear it from the cache.
Multiple QSOs with the same station do not appear under the Logbook tab either from the partial or Exact filters.

w4elp

2019-09-04 11:58

updater   ~0008508

Confirm G3UCQ's report that previous QSOs not appearing in Logbook tab of Logbook ALE.

Confirm G3UCQ's report that RESET then subsequent lookup of new call sign returns data from previous lookup. Have to cancel ALE and start new one to clear data, or it keeps returning data from first lookup.

Test feature on Logbook lookup settings results in Logbook crash. Tried with QRZ.com, Callook.com and HamQTH.com with same results. Minidump file attached HRDLogbook_20190904_154850.mdmp.

HRDLogbook_20190904_154850.mdmp (761,099 bytes)

WA9PIE

2019-09-21 14:00

administrator   ~0008570

I probably won't be able to add a whole lot more detail to this topic. Folks have made a number of observations. I've added some observations in a separate Mantis issue.

This is not ready. I'm failing the change.

WA9PIE

2019-09-22 01:29

administrator   ~0008571

Since the intended outcome of this change was to re-code the callsign lookup function, I've taken these items from 3065. They belong here:

These issues are all different than this issue, which tracks adding all fields to the list control in the test tab:

The "logfile" button in the Callsign Lookup tab's "Test" window no longer works.
Part of this change was to "lock" the "HRD Country list" at the bottom of the options.
Depending on which lookup option is enabled first, the fields in the test pane show up in a different order.
There are problems where the QRZ data is not being populated per the specification (Callsign Lookup 3.1).
I then add a different callsign but the previous callsign's data is also shown.

I'm going to pass 3065. It has - in-fact - served its purpose.

K5K (1).ADI (6,131 bytes)
CallsignLookupMapping32 (1).xlsx (25,244 bytes)

K7ZCZ

2019-09-24 19:14

administrator   ~0008636

These issues are all different than this issue, which tracks the fundamental re-write of the feature.


  • The "logfile" button in the Callsign Lookup tab's "Test" window no longer works.

  • Part of this change was to "lock" the "HRD Country list" at the bottom of the options.

  • Depending on which lookup option is enabled first, the fields in the test pane show up in a different order.

  • There are problems where the QRZ data is not being populated per the specification (Callsign Lookup 3.1).

  • I then add a different callsign but the previous callsign's data is also shown.


 
Please open individual items for each of these defects. Using separate Mantis issues for each individual issue will facilitate tracking and testing, and expedite fixes.

Since the fundamental issue of showing the fields is fixed, I'm marking this issue resolved.

WA9PIE

2019-09-24 22:56

administrator   ~0008651

Why aren't these part of the same change?

For example...

The logfile button worked before this change.
Locking the HRD Country List was an intended part of this change.
The test pane was changed as part of this change.
The QRZ lookup is not working per the written specs for this change. Are we meant to open new defects when the specs related to a specific change are not correctly coded?
The 5th defect could logically be a new one, but still created as a result of this change.

So I seek to understand. How do we handle defects that arise as a result of a given change? If the change does not satisfy the specifications for that change, then will this problem be resolved as part of this change... or each case where the change is not coded per the spec is a new Mantis issue?

K7ZCZ

2019-09-25 22:57

administrator   ~0008685

> How do we handle defects that arise as a result of a given change?

By opening individual issues for each problem, just like any other issue. A single issue that says "this feature doesn't work" is not useful for tracking progress on the work, or managing communications on the smaller issues that compose the larger effort.

Imagine that we have only one Mantis issue that tracks the five issues listed above. Two of the five are fixed. We can't resolve the mantis issue, since not all five are fixed -- so we can't start testing, ship anything, or clearly communicate about any of the incremental progress on the individual issues because they're jumbled into one single Mantis issue. Encumbering communication and making work less granular impedes progress.

On the other hand, say we have five individual Mantis issues. Two are fixed, so they can be marked resolved. Testing can start on them while, concurrently, the other three issues are worked. Maybe one of the remaining three is won't fix -- that disposition can be recorded independently of the other four, no problem. Very clear, easy to find, trivial to manage.

If any issue is a regression, it's even more important to have an individual issue for it since the notes in that issue are focused on the regression. They'll drive more focused testing and track implementation and repair. After all, if there's a regression, then the regression must indicate some issue that's problematic or controversial, and so it naturally deserves more focused attention.

We can sometimes get away with Mantis issues for large or exploratory work items. This issue and the Panadapter issue are examples. They're also examples of cumbersome management: no way to track progress on smaller, incremental deliverables; no good structure to manage related features. The work for this issue took more than two calendar months, and that was after the specification was written. Scrolling through the history here reveals at least seven check-ins.

The alternative is going dark for those months, then suddenly throwing something over the wall. That's the opposite of agile, transparent, flexible practice. This issue completely rewrote call sign lookup code for the whole product. The total impact is around 10,000 lines of code. Using a single Mantis issue for every newly noted call sign lookup problem from now on is not tenable. The problems would be multiplied had we other people trying to contribute to the same work at the same time -- Mantis issues have one owner, but when multiple work items are packed into the same Mantis issue, ownership isn't clear.

Practically, it's quite difficult to extract notes from mixed issues. Notes about issue A get conflated with notes for issue B because they're both in the same single Mantis issue and context gets confused, history is hard to read. If it turns out that multiple issues are actually fixed by the same root cause, combining them is trivial and takes only a couple of minutes -- a note about it, link the duplicate item, resolve as duplicate, done. Then, it makes perfect sense to err on the side of multiple reports (within reason, of course) than it does to try to use the same issue to somehow be more efficient or compact.

I hope that explains it; LMK if you have specific questions.

WA9PIE

2019-09-27 20:44

administrator   ~0008712

Yep, that's fine.

WA9PIE

2019-10-13 07:04

administrator   ~0008797

This is not done yet. There are a number of child cases for this. As a result, I'm holding it open and assigned to me until these other items are complete (which will complete this scope of work).

Issue History

Date Modified Username Field Change
2018-12-18 11:52 WA9PIE New Issue
2018-12-18 11:52 WA9PIE Status new => assigned
2018-12-18 11:52 WA9PIE Assigned To => K7ZCZ
2018-12-18 11:52 WA9PIE File Added: Callsign Lookup.docx
2018-12-18 15:23 K7ZCZ Assigned To K7ZCZ => WA9PIE
2018-12-18 15:23 K7ZCZ Status assigned => feedback
2018-12-18 15:23 K7ZCZ Note Added: 0006703
2018-12-20 12:05 WA9PIE Assigned To WA9PIE => K7ZCZ
2018-12-20 12:05 WA9PIE Steps to Reproduce Updated View Revisions
2018-12-20 12:05 WA9PIE Note Added: 0006735
2018-12-20 15:36 K7ZCZ Assigned To K7ZCZ => WA9PIE
2018-12-20 15:36 K7ZCZ Status feedback => new
2018-12-27 18:32 K7ZCZ Note Added: 0006818
2018-12-31 11:29 K7ZCZ Relationship added related to 0003015
2018-12-31 11:30 K7ZCZ Note Added: 0006829
2019-01-07 11:19 K7ZCZ Relationship added related to 0003047
2019-01-07 11:19 K7ZCZ Relationship added related to 0003046
2019-01-20 11:21 K7ZCZ Relationship added related to 0003049
2019-01-28 14:46 K7ZCZ Relationship added related to 0003130
2019-01-29 10:06 K7ZCZ Relationship added related to 0003135
2019-02-01 09:34 K7ZCZ Relationship added related to 0003145
2019-02-01 15:48 K7ZCZ Relationship added related to 0003147
2019-02-01 18:25 K7ZCZ Relationship added related to 0002262
2019-02-25 18:17 K7ZCZ Relationship added related to 0003196
2019-02-27 19:28 WA9PIE Relationship added related to 0003125
2019-02-28 01:31 WA9PIE Relationship added related to 0001395
2019-02-28 01:33 WA9PIE Relationship added related to 0003192
2019-02-28 16:08 WA9PIE Relationship added related to 0003187
2019-03-02 00:25 WA9PIE Status new => acknowledged
2019-03-02 01:03 WA9PIE Relationship added related to 0001660
2019-03-02 01:22 WA9PIE Relationship added related to 0000472
2019-03-02 01:22 WA9PIE Relationship added related to 0002006
2019-03-02 01:32 WA9PIE Relationship added related to 0001554
2019-03-05 23:41 WA9PIE Relationship added related to 0002883
2019-04-08 11:22 K7ZCZ Relationship added related to 0003284
2019-05-23 13:45 K7ZCZ Relationship added related to 0002909
2019-05-30 16:51 K7ZCZ Category Bug => Enhancement
2019-05-30 16:51 K7ZCZ Note Added: 0007958
2019-06-16 17:13 WA9PIE Note Added: 0008103
2019-06-16 17:13 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-06-16 23:25 K7ZCZ Note Added: 0008114
2019-07-11 14:23 K7ZCZ Relationship added related to 0003376
2019-08-01 11:52 K7ZCZ Relationship added related to 0002682
2019-08-14 14:38 K7ZCZ Note Added: 0008407
2019-08-23 16:01 K7ZCZ Note Added: 0008432
2019-08-24 12:53 K7ZCZ Relationship added related to 0003065
2019-08-26 11:18 K7ZCZ Note Added: 0008443
2019-08-26 11:52 K7ZCZ Note Added: 0008444
2019-08-26 13:40 K7ZCZ Note Added: 0008445
2019-08-26 14:09 K7ZCZ Note Added: 0008446
2019-08-26 14:13 K7ZCZ Status acknowledged => resolved
2019-08-26 14:13 K7ZCZ Resolution open => fixed
2019-08-26 14:13 K7ZCZ Note Added: 0008447
2019-08-27 10:08 K7ZCZ Note Added: 0008453
2019-08-29 15:01 K7ZCZ Relationship added related to 0003432
2019-08-30 16:00 K7ZCZ Fixed in Version => 6.7.0.226
2019-09-02 08:07 g3ucq Note Added: 0008492
2019-09-04 11:58 w4elp File Added: HRDLogbook_20190904_154850.mdmp
2019-09-04 11:58 w4elp Note Added: 0008508
2019-09-14 02:15 WA9PIE Relationship added related to 0003305
2019-09-21 14:00 WA9PIE Note Added: 0008570
2019-09-21 14:00 WA9PIE Status resolved => feedback
2019-09-21 14:00 WA9PIE Resolution fixed => reopened
2019-09-22 01:29 WA9PIE File Added: K5K (1).ADI
2019-09-22 01:29 WA9PIE File Added: CallsignLookupMapping32 (1).xlsx
2019-09-22 01:29 WA9PIE Note Added: 0008571
2019-09-22 01:29 WA9PIE Status feedback => assigned
2019-09-22 02:59 WA9PIE Tag Attached: ParityGap
2019-09-24 19:14 K7ZCZ Note Added: 0008636
2019-09-24 19:15 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-09-24 19:15 K7ZCZ Status assigned => resolved
2019-09-24 19:15 K7ZCZ Resolution reopened => fixed
2019-09-24 22:56 WA9PIE Note Added: 0008651
2019-09-24 22:56 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-09-25 22:20 WA9PIE Relationship added parent of 0003462
2019-09-25 22:49 WA9PIE Relationship added parent of 0003463
2019-09-25 22:57 K7ZCZ Note Added: 0008685
2019-09-25 22:58 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-09-27 20:44 WA9PIE Note Added: 0008712
2019-10-05 20:21 K7ZCZ Relationship added related to 0003464
2019-10-09 20:16 KC7FPF Relationship added parent of 0003484
2019-10-13 05:55 WA9PIE Relationship added parent of 0003492
2019-10-13 06:36 WA9PIE Relationship added related to 0003493
2019-10-13 06:37 WA9PIE Relationship deleted related to 0003493
2019-10-13 06:37 WA9PIE Relationship added parent of 0003493
2019-10-13 07:04 WA9PIE Status resolved => assigned
2019-10-13 07:04 WA9PIE Resolution fixed => reopened
2019-10-13 07:04 WA9PIE Note Added: 0008797
2019-10-13 07:25 WA9PIE Relationship added parent of 0003495
2019-10-13 07:46 WA9PIE Relationship added parent of 0003496
2019-10-13 08:30 WA9PIE Relationship added parent of 0003497
2019-10-13 09:03 WA9PIE Relationship added parent of 0003498
2019-10-13 09:15 WA9PIE Relationship added related to 0003499
2019-10-13 09:15 WA9PIE Relationship deleted related to 0003499
2019-10-13 09:15 WA9PIE Relationship added parent of 0003499