View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003001||Ham Radio Deluxe||Bug||public||2018-12-18 11:52||2019-11-10 06:47|
|Target Version||Fixed in Version||22.214.171.124|
|Summary||0003001: Callsign lookup function does not appear to be working as designed|
|Description||We 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 Information||The attached document describes the intended design of the Callsign Lookup function wherever it is used.|
|parent of||0003462||closed||K7ZCZ||Ham Radio Deluxe||call sign lookup options should always list Unique Call sign Database first|
|parent of||0003463||closed||WA9PIE||Ham Radio Deluxe||"Logfile" button in call sign lookup testing page is always disabled|
|parent of||0003484||closed||WA9PIE||Ham Radio Deluxe||Call sign lookup not working correctly or will freeze Logbook|
|parent of||0003492||closed||WA9PIE||Ham Radio Deluxe||Complete the Callsign Lookup function for the Country List method|
|parent of||0003493||closed||K7ZCZ||Ham Radio Deluxe||Complete the Callsign Lookup function for the QRZCQ method|
|parent of||0003495||closed||K7ZCZ||Ham Radio Deluxe||Complete the Callsign Lookup function for the Callook.info method|
|parent of||0003496||closed||WA9PIE||Ham Radio Deluxe||Complete the Callsign Lookup function for the QRZ.com Subscription method|
|parent of||0003497||closed||WA9PIE||Ham Radio Deluxe||Complete the Callsign Lookup function for the Logbook method|
|parent of||0003498||closed||WA9PIE||Ham Radio Deluxe||Complete the Callsign Lookup function for the UCSDB (Public) method|
|parent of||0003499||closed||WA9PIE||Ham Radio Deluxe||Complete the Callsign Lookup function for the UCSDB (Private) method|
|parent of||0003510||closed||K7ZCZ||Ham Radio Deluxe||Some HamCall.net fields are not being populated|
|parent of||0003376||closed||KC7FPF||Ham Radio Deluxe||Incorrect QTH Data|
|parent of||0003546||closed||K7ZCZ||Ham Radio Deluxe||Callook.info, the Callsign Lookup does not correctly assign DXCC, Country, Continent, and HRDCountry|
|related to||0003015||closed||K7ZCZ||Ham Radio Deluxe||Logobook ALE lookup code is overrun by copy-and-paste|
|related to||0003047||closed||K7ZCZ||Ham Radio Deluxe||move "Test" feature of Logbook's Callsign Lookup config to its own property page|
|related to||0003046||closed||K7ZCZ||Ham Radio Deluxe||move controls for the config of each Logbook Callsign Lookup data source their own property page|
|related to||0003049||closed||K7ZCZ||Ham Radio Deluxe||V126.96.36.1997 - ALE showing Double City in fields|
|related to||0003130||closed||PD9FER||5 - Closed w/o Action||Logbook ALE lookup disregards position set in Callsign Lookup order|
|related to||0003135||closed||K7ZCZ||Ham Radio Deluxe||Logbook's MessageDate() function isn't useful|
|related to||0003145||closed||K7ZCZ||Ham Radio Deluxe||Enhance logging output of callsign lookup feature|
|related to||0003147||closed||K7ZCZ||Ham Radio Deluxe||Logbook callsign lookup data source doesn't return much data|
|related to||0003196||closed||K7ZCZ||Ham Radio Deluxe||Logbook QTH Column Issue|
|related to||0003192||closed||WA9PIE||Ham Radio Deluxe||Lat/Long, direction, and distance are incorrect in the Logbook ALE; "Log Coordinates" has opposite affect|
|related to||0003187||closed||WA9PIE||Ham Radio Deluxe||V188.8.131.52 to 184.108.40.206 has problems with the Callsign Lookup Pane in the Logbook.|
|related to||0001660||closed||WA9PIE||Ham Radio Deluxe||Use Maidenhead locator (grid square) for ALE coordinates|
|related to||0003284||closed||K7ZCZ||Ham Radio Deluxe||remove support for QRZ CD lookup|
|related to||0002909||closed||K7ZCZ||5 - Closed w/o Action||Logbook: remove support for SAM Callsign CD lookups|
|related to||0003065||closed||WA9PIE||Ham Radio Deluxe||Add all fields to the Callsign Lookup function's Test tab|
|related to||0003432||closed||PD9FER||Ham Radio Deluxe||When doing lookups with same station worked before, RST is set to latest QSO RST|
|related to||0003305||closed||PD9FER||Ham Radio Deluxe||Logbook crashes on Callsign Lookup|
|related to||0003464||closed||WA9PIE||Ham Radio Deluxe||Some fields missing from QRZ.com call sign lookup|
Callsign Lookup.docx (281,495 bytes)
||Is this issue about fixing the specific problem that customer reports, or is it about implementing the attached specification in its entirety?|
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.
A bit of code cleanup with this checkin:
||Mantis 3015 cleans up the ALE lookup implementation significantly. More work to do, but this helps it become approachable.|
||Switched to "enhnacement" per the team call on 2019-05-30|
||Any more specific questions? I don't see this happening until after the first 6.7 release.|
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.
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.
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.
This hooks up the new code to DM780 via the IPListener interface
removal /cleanup of old implementation:
more cleanup, hook up UDP Listener:
This checkin removes more old code, including the HRDLogbookCallsignLookup DLL.
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 ...
Removes a few more obsolete definitions from the code:
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.
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)
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.
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)
These issues are all different than this issue, which tracks the fundamental re-write of the feature.
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.
Why aren't these part of the same change?
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?
> 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.
||Yep, that's fine.|
||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).|
NOTE for the Beta team; guidance for testing these changes:
Design criteria 1: The way this is designed to work is that the user can enable selected callsign lookup methods as they desire. The data is populated based on the order in which the user lists them. The "Enabled Method" at the top populates all vacant fields. Then the next "Enabled Method" populates any remaining fields... and so on. Generally, the user should put those methods at the top that they feel are most accurate/specific... with those that are less accurate/specific at the bottom (I'll get to a related point about the Country List in a moment.).
Design criteria 2: The UCSDB (Public) is always going to be the first source used. We (HRD Software) make the updates to that data. The UCSDB (Private) is always going to be the second source used. Both of these methods have always been used before any "Enabled Method." The reason for this is that it is a source that we or the user have validated and we know it to be accurate. The user will not have the ability to change the priority that users these lookup methods.
Design criteria 3: The Country List does not use specific data records that were created by human beings. That is - the UCSDB and all the other lookup sources have actual data in them that is specific to a callsign and it was validated by a human. The Country List does not. The Country List uses "regular expression" logic to attempt to determine the Country based on the prefix of the callsign being logged. As such, the method of trying to determine the Country (DXCC number, Continent, and HRDCountryNumber) from this method is the least accurate method. For this reason, I consider it to be "the source of last resort." It should be pinned to a position below all other Enabled Methods.
Design criteria 4: When the response from an Enabled Method contains the DXCC numeric for a given callsign, then that DXCC number describes the country explicitly and without ambiguity. We then cross reference the Country List for that DXCC numeric to populate Country, Continent, and the HRDCountryNumber. We do not use the Country or Continent from the Enabled Method even-if that Enabled Method contains such data. The reason for this is that the Country List contains the exact spelling for each country. Some lookup methods may have "United States", "United States of America", "US", or "USA" for Country. Some lookup methods could use "NA" or "North America" for Continent. For consistency of data, the cross reference for an Enabled Method ensures that the record is populated with the exact Country, Continent, and HRDCountryNumber referenced by the DXCC numeric in the response from the lookup method.
Testing: I recommend that you begin by testing one "Enabled Method" at-a-time. The Country List should always be the last option (I'd like to get it removed from the list and shown below enabled methods; but we'll tackle that later).
Once all the lookup sources have been tested independently, then adding more than one and experimenting with the order would be the next approach.
Using Logbook and Country List, in that order, the ALE was populated correctly for two call signs.
The problem of the ALE being populated from a previous QSO incorrectly is no longer an issue.
The changes we needed to make were mostly related to the population of other fields (like QTH). There were such problems with it all, that Mike rewrote the whole thing.
We won't see those changed until the next 6.7 beta version. I expect that could come soon.
Using Logbook and Country List, in that order, the ALE was not populated for two previously worked call signs, neither was the data for the Logbook tab.
The problem of the ALE being populated from a previous QSO is an issue.
Something broke after v 220.127.116.11
Right. Since the 6.6.x.x release, Mike has completely rewritten the callsign lookup. All 6.7.x.x beta versions have that (incomplete) change in them.
Suggested call to test with = KH0A
I'm looking forward to the next beta so that we can test these changes fully.
||All the work related to this issue have been validated.|
I have updated the field mapping specification with the as-built condition. It has been posted here:
GDFS:\Shared drives\HRD Software\Functional Specifications\Callsign Lookup\CallsignLookupMapping (4.1) as-built in v6.7 release.xlsx
|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||=> 18.104.22.168|
|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|
|2019-10-19 18:32||WA9PIE||Note Added: 0008874|
|2019-10-19 18:35||WA9PIE||Note Edited: 0008874||View Revisions|
|2019-10-20 00:42||g3ucq||Note Added: 0008875|
|2019-10-20 00:59||WA9PIE||Note Added: 0008876|
|2019-10-20 01:01||g3ucq||Note Added: 0008877|
|2019-10-20 01:10||WA9PIE||Note Added: 0008878|
|2019-10-22 19:03||WA9PIE||Relationship added||parent of 0003510|
|2019-10-23 03:59||WA9PIE||Relationship deleted||related to 0003376|
|2019-10-23 03:59||WA9PIE||Relationship added||parent of 0003376|
|2019-10-29 05:26||WA9PIE||Relationship deleted||related to 0002262|
|2019-10-29 05:29||WA9PIE||Relationship deleted||related to 0001395|
|2019-10-29 05:33||WA9PIE||Relationship deleted||related to 0000472|
|2019-10-29 05:33||WA9PIE||Relationship deleted||related to 0002006|
|2019-10-29 05:33||WA9PIE||Relationship deleted||related to 0001554|
|2019-10-29 05:34||WA9PIE||Relationship deleted||related to 0002883|
|2019-10-29 05:37||WA9PIE||Relationship deleted||related to 0002682|
|2019-10-29 05:37||WA9PIE||Relationship deleted||related to 0003125|
|2019-10-29 05:38||WA9PIE||Status||assigned => closed|
|2019-10-29 05:38||WA9PIE||Resolution||reopened => fixed|
|2019-10-29 05:38||WA9PIE||Fixed in Version||22.214.171.124 => 126.96.36.199|
|2019-10-29 05:38||WA9PIE||Testing||Not Started => Beta Successful|
|2019-10-29 05:38||WA9PIE||Note Added: 0009068|
|2019-10-29 05:38||WA9PIE||Category||Enhancement => Bug|
|2019-11-06 16:20||WA9PIE||Relationship added||parent of 0003546|
|2019-11-08 02:10||WA9PIE||Fixed in Version||188.8.131.52 => 184.108.40.206|
|2019-11-08 02:32||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|
|2019-11-10 06:47||WA9PIE||Note Added: 0009225|