View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3646 [3 - Current Dev List] Maintenance minor always 2020-03-09 10:47 2020-07-07 23:37
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: copyright Date not updated
Description: Copyright date in Rig control says 2003 - 2019 instead of 2003 - 2020
Tags:
Steps To Reproduce: Start Rig Control
Close connection to Radio
Look at main screen, you will see 2019 instead of 2020
Same is true when going to Help > About

Additional Information: Ticket 635391
Attached Files:
Notes
(0009710)
WA9PIE   
2020-07-02 07:03   
Doug - see if you can update this one if it's an easy modification.
(0009732)
DOUG   
2020-07-07 23:37   
have this change done, I will put it in a build soon

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3701 [1 - Backlog] Bug major always 2020-07-07 09:12 2020-07-07 09:12
Reporter: k2ie Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing:
Summary: Lookup while in update mode overwrites QSO date/time
Description: This may have been introduced as part of the fix for 0003663.

QSO date/time is overwritten if an existing record is opened for edit and the lookup function is used to populate missing fields. This could be necessary, for example, to populate the mailing address of a QSO that was imported form an ADIF produced by contest logging software.

Pressing lookup while in update should not reset the QSO date/time values.
Tags:
Steps To Reproduce: Open any existing QSO for edit.
Note the recorded start and end date/time for the QSO.
Press the lookup button.
Note that the date/time values were changed.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3665 [3 - Current Dev List] Enhancement feature N/A 2020-04-10 03:14 2020-07-06 23:13
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.7.0.282  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6.7.0.285  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Add option to include Comment field from prior QSO to be included in callsign lookup
Description: Add option to that allows the contents from the most recent QSO's Comment field to be pulled in during the callsign lookup process when Logbook is an enabled method.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 3665_282.PNG (58,666 bytes) 2020-06-18 14:43
https://development.hamradiodeluxe.com/file_download.php?file_id=976&type=bug
png
Notes
(0009689)
WA9PIE   
2020-06-12 21:17   
It looks like the option for this showed up in the 6.7.0.280 build. It's not working.

What should happen is...

When this option is enabled, and the user invokes the callsign lookup within the ALE, the contents of the last QSO with that callsign is brought into the ALE so that the user can see it... then they can leave it, delete it, or modify the contents of the Comment field prior to saving the new QSO.
(0009692)
WA9PIE   
2020-06-18 01:24   
No change in 6.7.0.282
(0009696)
WILL   
2020-06-18 14:43   
I think there's something I'm not understanding with this issue. When I lookup in the ALE it adds the last comment to the comment field. I attached a snip of what my screen looks like. Is there somewhere else the comment needs to show up?
(0009713)
WA9PIE   
2020-07-02 07:16   
I re-tested this in the 285 build and it seems to be working. Either I hadn't checked the option, or the code wasn't checked in when the last build was created.

I'm sending this to the beta testers.
(0009714)
g3ucq   
2020-07-02 07:39   
Fixed.
(0009719)
k2ie   
2020-07-02 09:36   
Tested with and without loopkup option checked, worked as expected in each case.
(0009720)
w4elp   
2020-07-02 09:50   
In 6.7.0.285 Beta, comment from previous QSO appears in Logbook ALE regardless of option setting. In DM780 ALE, comment from previous QSO does not appear, regardless of option setting.
(0009721)
w4elp   
2020-07-02 09:57   
Correction to previous note - After more checking and unchecking the option, it appears to be working correctly in Logbook ALE. Comment still does not appear in DM780 ALE regardless of option setting.
(0009731)
WA9PIE   
2020-07-06 23:13   
Doug - is it possible to take a look at DM-780 and see what it would take to make this same change happen in DM-780's ALE?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3260 [4 - Business Priorities] Bug minor always 2019-03-26 10:10 2020-07-05 00:26
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Rotator application, Gauge is not letting it resize
Description: When it the Rotator application with the Gauge(s) displayed, it was revisable in the past.
Now it wont let you drag it to a bigger size.
Tags:
Steps To Reproduce: Start rotator application
Try dragging one of the borders to resize the Gauge.
It looses focus and won't resize.
Additional Information: Ticket 631822
Attached Files: rotator.jpg (130,283 bytes) 2019-03-26 10:10
https://development.hamradiodeluxe.com/file_download.php?file_id=703&type=bug
jpg
Notes
(0009283)
PD9FER   
2019-11-12 07:51   
Ticket #245164 is a bit upset that this still is not done.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3656 [4 - Business Priorities] General minor always 2020-03-30 21:34 2020-07-05 00:16
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.7.0.282  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Alpha Failed
Summary: Increment SSID on DX cluster reconnect to eliminate the ping-pong of login/logout events on DX clusters
Description: DX clusters do not permit multiple login sessions with the same unique callsign. (This is likely to avoid having to deal with abandoned connections.)

As such, DX clusters are capable of allowing a unique user to connect multiple times by adding a 1 or 2 digit numeric number after the call in this format: <callsign>-xx

This 2-digit number is referred to as a "system ID", or SSID.

Ham Radio Deluxe Logbook allows for this in the DX Cluster Options > Connection tab (reference here: https://wiki.hamradiodeluxe.com/index.php?title=Logbook#Connection)

The purpose of this change is to propose a remedy where the SSID is incremented automatically within Ham Radio Deluxe Logbook when the application is set to reconnect.
Tags:
Steps To Reproduce: Set up two separate instances of Ham Radio Deluxe, both connecting to the same DX cluster, both with the same callsign.

You'll see them ping-pong back-n-forth. The result looks like this:

User WA9PIE has logged in
User WA9PIE has logged out
User WA9PIE has logged in
User WA9PIE has logged out
User WA9PIE has logged in
User WA9PIE has logged out
User WA9PIE has logged in
User WA9PIE has logged out
User WA9PIE has logged in
User WA9PIE has logged out
User WA9PIE has logged in
User WA9PIE has logged out

The telnet session will see this message when it disconnects:
Reconnected as <callsign> at <IP address>, this instance is disconnected

In practice, it would look like this:
Reconnected as WA9PIE at 67.121.49.7, this instance is disconnected
Additional Information: While we could watch the Telnet session for "Reconnected as <callsign> at <IP address>, this instance is disconnected", it's probably move involved from a development effort perspective.

RECOMMENDATION:
- In the DX Cluster Options > Connection tab, there's an option there that says, "Reconnect if connection lost"
- Add code that will cause the SSID (shown in the connection tab) to automatically increment when the connection is lost (or when the "reconnect" code runs); this information is stored in the an XML file for the user
- Add an option to enable/disable this "Increment SSID when connection lost"; default it to [Enabled] (point here is - if someone knows enough to disable it, they must know that they're managing their SSIDs properly; put this option under the existing "Reconnect if connection lost" option in DX Cluster Options > Connection tab

NOTE: SSID values range from "None" to 15. So the rotation would be "None", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, "None", 1, 2, 3, 4, 5, 6...
Attached Files: 3656_282_1.PNG (15,379 bytes) 2020-06-18 17:02
https://development.hamradiodeluxe.com/file_download.php?file_id=977&type=bug
png

3656_282_2.PNG (99,524 bytes) 2020-06-18 17:02
https://development.hamradiodeluxe.com/file_download.php?file_id=978&type=bug
png
Notes
(0009682)
DOUG   
2020-05-24 15:10   
Just kicked off the beta build with this one in it, needs validation.
(0009694)
WA9PIE   
2020-06-18 07:45   
I tested this in the 282 build and it's not correct yet.
(0009698)
WILL   
2020-06-18 17:02   
I think I'm missing something here. Here's what happens for me. I have two logbooks open. On logbook1 I connect WA9PIE-2 with WA9PIE ( I don't actually have a valid call sign) and with logbook2 I connect to WA9PIE-2 with WA9PIE. Logbook1 gets disconnected and then after a wait reconnects with WA9PIE-1 while logbook2 stays logged in. I attached screenshots of this happening. I had to do this with the debug build so I could change my call sign.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2577 [4 - Business Priorities] Bug major always 2018-03-07 08:37 2020-07-05 00:16
Reporter: k2ie Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Frequency RX is blanked from existing log entry when updating record
Description: There is a logbook field called Frequency RX that is optionally recording during a split frequency QSO as long as the ALE Save VFO B option is checked. Data is also recorded in this field if an API insert submits it. However, if the record is later updated for any reason (QSL info or qrz.com update are 2 possibilities), the Frequency RX data is wiped out UNLESS Save VFO B is checked.
Tags:
Steps To Reproduce: 1. Log a QSO with split RX/TX frequencies.
2. Verify using the log view that both RX and TX frequencies have been recorded. You'll have to add Frequency RX to the layout.
3. Update the QSO after making some trivial change.
4. Verify using the log view that the Frequency RX field for that record is now blank.
Additional Information: Discussed in Beta Forum thread: https://forums.hamradiodeluxe.com/node/45218
Attached Files:
Notes
(0004449)
g3ypp   
2018-03-07 09:48   
I can replicate the reported bug
BUT also noted that when operating simplex, the same frequency is recorded in both columns ie "Freq" and "Freq(Rx)" irrespective of the frequency or band set on the sub VFO, VFO B whatever you want to call it.
The 2 entries are only different when I operate in "Split".
But in Split mode the "Freq" column contains the Rx frequency, and the "Freq(Rx)" column contains the Tx frequency. This is about face as they say.
I have an IC07600 V2
(0005486)
k2ie   
2018-06-25 14:51   
See also 1608 and 580.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3632 [3 - Current Dev List] Bug major always 2020-02-03 07:41 2020-07-04 10:27
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Filling in a Call in ALE and Hit Enter takes long time to be written to the DB
Description: When you normally open the ALE, you Type the Call and select Tab/lookup
Then F7 to add it to the log.
This works fast

Some customers report that when the type the call into the ALE and hit Enter, it takes a long time to be written to the DB
Tags:
Steps To Reproduce: Open ALE
Enter a Call
Do a TAB or select Lookup
Hit F7
This would write directly to the database

Now:

Open ALE
Enter a call
Hit Enter
This takes longer to write to the Database

Or:
Disable all Calsign Lookup options
Open ALE
Enter a call (DO NOT use Lookup!)
Hit Enter
This takes longer to write to the Database
Additional Information: Ticket #855268
Ticket #796013
Attached Files:
Notes
(0009574)
PD9FER   
2020-02-03 08:05   
As an addition:
Open ALE
Type a call
Hit F7
This is also slow...

Conclusion: Writing to the DB is slow when not doing a Lookup.
(0009648)
PD9FER   
2020-04-05 04:09   
Ticket #236929
(0009679)
PD9FER   
2020-05-22 10:26   
New one: Ticket #350414
(0009702)
PD9FER   
2020-06-26 11:49   
This is happening wit Access Database aswell as with MariaDB

You can also replicate this by removing all Callsign Lookup entries from Tools > Configure > Callsign Lookup
then try to add a contact.. it is slow.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3689 [3 - Current Dev List] Bug major always 2020-06-03 17:20 2020-07-02 07:04
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Cannot connect to DX cluster when the user has selected a callsign to use that contains a slash character
Description: Now that we have the ability to add callsigns for customers in QLM, we have requests for those callsigns to include a slash character. Examples include - VK4/WA9PIE, WA9PIE/M... and so on.

At present, the value used for connecting to the DX cluster comes from: Computer\HKEY_CURRENT_USER\Software\Amateur Radio\HRD User Profile\WA9PIE\Callsign (where WA9PIE is the station profile being used)

We need to change it so that the value used for connection to the DX cluster comes from: Computer\HKEY_CURRENT_USER\Software\Amateur Radio\HRD User Profile\WA9PIE\Operator
Tags:
Steps To Reproduce: Use a call that has a key assigned to it in QLM
Add a slash as an additional call
Attempt to connect to a DX cluster using the slash call as the active callsign
The DX cluster connection fails because they don't support slashes in the call
Additional Information: This change will cause the Operator value to be sent to make the DX cluster connection, rather than the Callsign value. This will correct the problem.
Attached Files: CHANGE-DXclusterCallsign.png (316,075 bytes) 2020-06-03 22:03
https://development.hamradiodeluxe.com/file_download.php?file_id=968&type=bug
Notes
(0009712)
WA9PIE   
2020-07-02 07:04   
Doug - can you take a look at this one?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3695 [3 - Current Dev List] Bug major always 2020-06-21 18:46 2020-07-02 07:04
Reporter: WA9PIE Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Additional callsigns with prefix that do not contain a number are not showing in My Station
Description: With the implementation of QLM, we are able to add additional callsigns to a key through "Product Properties." When additional callsigns are added into Product Properties for a given key, they are added as text separated by commas.

Some additional callsigns have a "prefix". This is the text that precedes the callsign before a slash. For example:

WA9PIE is a callsign
TI4/WA9PIE is a callsign with a prefix

When the prefix contains a number ("TI4"), this feature works perfectly.

When the prefix does not contain a number ("TI"), the feature does not work.

We believe that this is a limitation imposed via code in our software. (ie. The problem is not in QLM.)
Tags:
Steps To Reproduce: > Go into QLM for a given key (your personal key or a test key).
> Edit your key
> Go to the "Product Properties" tab
> Enter "TI4/WA9PIE" into the field; launch Logbook; observe the "TI4/WA9PIE" tab in Logbook's My Station (Tools > Configure > My Station); this works
> Change the additional callsign to drop the "4" so it reads "TI/WA9PIE"; observe that the call does not appear in Logbook's My Station
Additional Information:
Attached Files:
Notes
(0009711)
WA9PIE   
2020-07-02 07:04   
Doug - can you take a look at this one?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3615 [4 - Business Priorities] Bug major have not tried 2019-12-05 18:29 2020-07-02 02:28
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Parent issue for QSL labeling issues
Description: I'm creating this just to have a place to track the overall QSL labeling issues.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: actual-label.jpg (830,098 bytes) 2020-05-10 11:55
https://development.hamradiodeluxe.com/file_download.php?file_id=962&type=bug
label-print-main-screen.jpg (454,384 bytes) 2020-05-10 11:55
https://development.hamradiodeluxe.com/file_download.php?file_id=963&type=bug
Notes
(0009677)
w6hdg   
2020-05-10 11:55   
Main issue with my QL-570 is that the label produced has super tiny type. This is due to fixed left and right margins (see label produced). The nice thing about continuous labels is that margins are not necessary. If you used all of the real estate, the font could be bigger. Also:

Bugs that need fixing:
1) As shown on the bigger image, what you see is not what you get. The screen shows overlap (and that is probably why "auto" font is selecting a tiny font). But using a font size of 7 the label just fits.
2) In "Edit Label" you can set the height to any number and it always spits out a 1" high label - so it is not reading this value. But 1" is better than the 6" label with lots of white space I used to get with v. 6.5 of HRD
3) Setting the label width to no higher than 63 prevents cutting off characters on the right - but clearly more of the label should be used to allow the font size to increase further. There seems to be fixed margins that don't need to be there for a 62mm wide label.
4) Most fonts are way too wide and overlap when printed. I found this one font that was condensed enough.
5) "QSL Modern" works but "QSL Traditional" must use even more tiny type. I prefer the layout of QSL Traditional, so more work needs to be done so that the font can be at least 7 points.
6) Some labels such as DK11201 have height and width defined as just 1 or 2 mm - obviously bad data.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3621 [4 - Business Priorities] Bug minor always 2019-12-13 19:41 2020-07-02 02:25
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: Enabling PayPal as a form of payment for auto-orders
Description: Aside from auto-orders, PayPal accounts for 50% of our orders. I've had people tell me that they would purchase the auto-order IF they could use PayPal. I'm not sure what PayPal has done, but they're no longer supporting the integration that you guys built for that. This isn't going to stop us from offering/selling auto-orders. But it would absolutely increase the participation.
Tags: AutoRenewals
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3620 [4 - Business Priorities] Bug minor always 2019-12-13 19:40 2020-07-02 02:25
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: Sorting out the problem with the 15005 transaction failures
Description: I've been so busy in my day-job this week that I haven't been able to help the staff tend the flood of complaints and confusion. It doesn't sound like moving to WePay would solve this, because the existing transaction wasn't made there. I didn't speak with PayFlow, Randy did (and he's not deep in this topic; I tried to prepare him for the conversation). But if you're right... that the transactions are being declined because the CVV field is empty, can't we send the renewal transaction to PayFlow without a CVV field?

I have no idea how to solve this. But I'm not comfortable pushing/selling any new auto-orders until we sort this out.
Tags: AutoRenewals
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3619 [4 - Business Priorities] Bug minor always 2019-12-13 19:39 2020-07-02 02:25
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: Complaints that the renewal transaction is happening too far in advance of the expiration date of their maintenance plan
Description: I've had a whole lot of customers who have complained that their auto-order transaction happened weeks in-advance of the expiration date of their maintenance plan. I've personally canceled quite a few auto-orders as a result of these complaints.

If we're obtaining the maintenance plan expiration date and storing it in UC (as we do the key), can we take that date and copy it into the "Next Shipment" date field in the auto-order (please)?

And... sorry to ask, but... if this can be done, is it possible to run a one-time update of the auto-orders to get the maintenance plan expiration date copied into the "Next Shipment" date field for all the existing auto-orders?

This would actually be a beautiful thing. The customers would actually think we have a clue about running a business. (One customer wanted to file a complaint with the BBB about our "shady business practices.")
Tags: AutoRenewals
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3618 [4 - Business Priorities] Bug minor always 2019-12-13 19:37 2020-07-02 02:25
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: QLM/UltraCart - find a way to stop sending renewal reminders to customers who have purchased the auto-renewal
Description: QLM sends renewal reminders to ALL customers 30, 15, and 3 days in-advance of their maintenance plan expiration - including those who have purchased the auto-renewal. This causes problems where:

- customers get confused and buy again; because of that...
- customers are angry because they think we've charged them twice without their authorization
Tags: AutoRenewals
Steps To Reproduce: (steps not needed here)
Additional Information: Working with both Soraco and UltraCart, I've suggested the following to UltraCart as advised by Soraco:

Soraco now says that the advice they gave us previously for setting the "AffilliateID" would only work for the "initial order." That obviously won't work in our case because a renewal is never the "initial order." I explained that to them and they provided the following:

You can call the UpdateLicenseHttp function to update the affiliate ID
https://support.soraco.co/hc/en-us/articles/360000153826-UpdateLicenseHttp-?source=search&auth_token=eyJhbGciOiJIUzI1NiJ9.eyJhY2NvdW50X2lkIjo0NzQxNTcsInVzZXJfaWQiOjQzNjY2NjIxMDMsInRpY2tldF9pZCI6MTM1NDMsImNoYW5uZWxfaWQiOjYzLCJ0eXBlIjoiU0VBUkNIIiwiZXhwIjoxNTc4NzUwMDk1fQ.fWlDkixIh868ybwvdUg-tB9EeS6tEFluPZ17niiMnEI

Example (make sure to replace the activation key, product id, major version and minor version with their proper values according to your own product):

https://quicklicensemanager.com/hrdsoftwarellc/qlmlicenseserver/qlmservice.asmx/UpdateLicenseHttp?is_avkey=ARGN0B0T00HV5CWV8JHU1T1GZW&is_productid=3&is_majorversion=6&is_minorversion=6&is_affiliateid=AutoRenew&is_vendor=ultracart&is_user=xxx&is_pwd=yyy

If this method works, we may as well send this on all transactions - is_affiliateid=HRDPSL, is_affiliateid= HRDSMS, and is_affiliateid= HRDSMA (auto-order). Each time someone makes a purchase, their "affiliateid" would get updated with their most current item. Then we would only send the renewal orders when "AffiliateID <> HRDSMA".

We would need to obtain the key - which should already be in the customers UC profile. The productid, majorversion, and minorversion aren't changing. These are already in the Digital Delivery form.

I'm not trying to tell you how to do this (if you will do this), but (from a UI perspective) it looks like you would just add the AffiliateID field to the Digital Delivery form. For all I know, this is the string you're already sending at the time of the renewal purchase. I could get Doug to update existing customers.

We would need this to trigger along with any auto-order transactions - including existing auto-order transactions the next time they repeat.

This would solve the problem of reminder emails getting sent to customers who are in the auto-order program. This would also enable me to send them a custom reminder telling them that their auto-order is about to be placed so they're not surprised by it.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3421 [4 - Business Priorities] Bug major always 2019-08-10 22:28 2020-07-02 02:25
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Functional
Testing: Not Started
Summary: Fix the entitlement issue when PayPal is used (UltraCart)
Description: We have a number of support tickets where customers attempt to purchase a renewal and they receive the following error during checkout:

"An existing software entitlement for HRDSMS can not be located on your customer profile. Please contact customer service for assistance renewing this software entitlement."

Tags:
Steps To Reproduce: Basically, the scenario works like this...

User puts HRDSMS (or a kit containing it) in his cart, clicks on Checkout... then they select either Express Checkout or an Existing Profile (it makes no difference)... after that choice is made, there is definitely a step here where the entitlement is checked. It passes this time because they're using the same email address that's in their UltraCart profile.

Then they choose form of payment - credit card or PayPal.

If they choose credit card, it's all fine.

If they choose PayPal... they get redirected to PayPal (to login and authorize the payment)... that brings them back to checkout... there's a box they need to check to accept the terms... then they click on submit (or whatever button is the final purchase button; I'm not going through it right now).

When that happens (my theory is)... the email address associated with the PayPal account gets checked now for entitlement (rather than the email address in the UltraCart profile). Because they don't match, the user gets that error.

I watched a guy do this tonight (N4MAV@arrl.net)... watched him get the error... asked him to change his form of payment from PayPal to credit card and it worked perfectly.
Additional Information: I have contacted UltraCart with this information.
Attached Files:
Notes
(0008419)
WA9PIE   
2019-08-18 02:44   
I'm working to verify, but the error may be gone, but there's another problem related to which email address is being sent to QLM and which UC profile is being updated.
(0008977)
WA9PIE   
2019-10-23 08:20   
Updating this...

Jonathan at UltraCart made a change that may have resolved the problem. We just need to watch for a bit to determine if it actually did resolve the problem (repro cases are difficult.)
(0009119)
WA9PIE   
2019-11-03 01:41   
I reopened this based on the comments in the following support ticket: #835944 (HRDLL-201910311956-422477)

I've sent the detail to UltraCart.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3191 [4 - Business Priorities] Bug major always 2019-02-22 08:40 2020-07-02 02:25
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: V6.5.0.195 BETA "Logbook > File > Edit Selections > Manager"
Description: When opening the selections menu and choosing TOP 100, TOP 200.... etc, the filter allows only the most recent 100, 200, etc logbook records to be displayed as it should.

If you select a year it appears to display ALL records. Also if you attempt to edit one of the yearly filters, and enable it. Once you close the Selections menu and reopen it, the filter you just enabled will be disabled, so apparently the dialog is not permitting the filter to be saved to the xml file.

Ticket #189417 - n the Logbook, under Log Book Display, under config, the Selection for All, 100, 500, 1000, 2019, 2018, 2017, 2016, and so on .

The years do not work when I clic on them I get 0 QSOs.

ssb and cw and the all, 100, 500, 1000, work just find.

If I am missing 2018 QSOs can I find them on LOTW and down load them to the HRD logbook?
I had a computer change the old one was replace with a new one. I cannot believe that I have no 2018 QSOs.
Tags:
Steps To Reproduce: Ticket #417924 - Seth posted 02/19/2019 2:35 PM
I am unable to enter the fields for a new selection in HRDLogbook. To reproduce the problem:
1) On main menu go to Logbook/File/Edit Selection/Manager
2) Create a new selection (or copy an existing one)
3) Click on the Fields tab, select enable and enter some criteria. I tried several, all of them exhibited the issue. For this example, set Country not equals United States.
3) Select OK.
4) Pick the selection just created. All countries will show, including United States.
5) Edit the selection that was just created and the field selecting Country will no longer be selected.

I have been able to create and use selections in prior versions of HRD. Looking at the query saved in the LogbookQueries.xml file I see that the information in the Match Field tag wasn't saved for my new query. If I edit the file by hand I can get the query I desire. If I use the UI to modify the query the XML is unchanged. It appears that the fields information is not being saved.
Additional Information:
Attached Files:
Notes
(0009539)
PD9FER   
2020-01-09 03:04   
Ticket #191248 also has issues with it in 6.7.0.254
(0009671)
KB3NPH   
2020-04-23 09:14   
Ticket #106058 v6.7.0.275 has numerous issues with the Selections option in Logbook. Can't view any of the preset selections other than ALL. Can't create new selections in the Manager. When a new one is created it comes up blank.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3297 [5 - Closed w/o Action] Bug minor have not tried 2019-04-16 10:09 2020-07-02 02:24
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Another Test Issue
Description: Another Test Issue
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screen Shot 2019-04-16 at 8.07.43 AM.png (64,205 bytes) 2019-04-16 10:09
https://development.hamradiodeluxe.com/file_download.php?file_id=723&type=bug
png
Notes
(0007870)
WA9PIE   
2019-04-17 18:01   
Adding a new comment here to see what the email shows.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3296 [5 - Closed w/o Action] Bug minor have not tried 2019-04-16 10:08 2020-07-02 02:24
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Test Issue
Description: Test Issue
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screen Shot 2019-04-16 at 8.07.43 AM.png (64,205 bytes) 2019-04-16 10:08
https://development.hamradiodeluxe.com/file_download.php?file_id=722&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2926 [3 - Current Dev List] Maintenance tweak always 2018-10-30 08:05 2020-07-02 02:23
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: IOTA
Testing: Not Started
Summary: New and altered IOTA data in Logbook
Description: https://www.iota-world.org/info/new_groups_2018.pdf

There are some changes/additions in the IOTA designators (see link above)
Customer worked a station in IOTA NA-249P but it is not in the list.
Tags:
Steps To Reproduce: Open ALE
Open the IOTA List dropdown
Look for NA-249 It is not there.

Additional Information: Ticket #874915

Changes where made, use the link https://www.iota-world.org/info/new_groups_2018.pdf
for those.

The file was provided by the IOTA site on RSGB in XML format (filename: fulllist.xml). Periodically, we downloaded it and made the update. It seems that there are new entries to this list.

Attached Files: response.json (1,356,459 bytes) 2019-12-02 00:24
https://development.hamradiodeluxe.com/file_download.php?file_id=881&type=bug
Notes
(0007401)
WA9PIE   
2019-02-15 11:02   
We've had a few more tickets on this topic and we should address it.
(0007724)
KB3NPH   
2019-03-23 07:26   
Ticket #827216 just received about when and how the IOTA in HRD would be updated.
(0007845)
K7ZCZ   
2019-04-09 11:18   
Where can I find documentation on the suggested API?
(0007846)
K7ZCZ   
2019-04-09 12:05   
I've dug around on their site a bit, and this is all I can find:
https://www.iota-world.org/management-news/896-calling-software-developers.html

so I've written the email address given there to request information about their API, licensing, and acceptable use.
(0007847)
K7ZCZ   
2019-04-11 05:18   
I got in touch with the IOTA team. A given API key is good for only 1000 queries per day, so we'll need to build a reflector -- in the same way we have for the solar weather data. We'll need to decide how that works, how often it updates, and how it is monitored.

Architecturally, we'll need to figure out how to handle the format change; the existing code expects an XML format for IOTA data, while the new format is JSON. Does the forwarding service provide XML, or JSON, or a completely new format? It's not much fun parsing JSON in C++, so it seems like we should stick with XML or invent our own format -- seems like CSV would be fine, and simpler and faster than XML. Either way, if we're not sending JSON to the applications, then we need to have code translate the JSON into the redistributed format rather than simply serve a specific file.

I'm not sure how these decisions should/would be addressed by the team.
(0007929)
WA9PIE   
2019-05-10 18:31   
Doesn't this API essentially build the list? And if so, can't we build the list once... at the time we compile code?
(0007931)
K7ZCZ   
2019-05-12 20:52   
If we build the list when the code is complied, then we won't pick up changes until the next version is compiled. Customers won't pick up the changes until the next time they install a new version. Building new versions of code to accommodate changes in external data doesn't seem like a good pattern to me.

Plus, as I detail above, the API produces data in a format that we're not prepared to consume.
(0007932)
K7ZCZ   
2019-05-13 12:57   
Attached are the IOTA docs I was sent. They're very scant--in particular, no meaningful definitions for each field in the data that's provided by the API.

On our side, we don't have any documentation for the existing IOTA XML format, or for any of the IOTA features themselves. This means we have to go through the code to figure out what the data does and what it's used for. Then, we'll need to get data from the new IOTA API and compare it to what we can infer about the old XML format to see if there's a direct replacement or not ... or if some translation is needed.
(0007933)
K7ZCZ   
2019-05-13 12:58   
second try at the attachment ...
(0007934)
K7ZCZ   
2019-05-13 12:59   
Looks like attachments aren't working right for me :(
(0009479)
PD9FER   
2019-11-29 04:27   
Ticket # 244581

Customer comment:
If maintaining the IOTA list is considered an enhancement it would be nice if I could manually enter this information. Otherwise I can't maintain an accurate log.

Also, here are more IOTA's that are missing from the list.
EU-192 OJ9, SM Kataja/Inakari Island

NA-249 KP3, 4 Puerto Rico's Coastal Islands
NA-250 KL Yakutat Borough group

OC-297 FO Morane Atoll
OC-298 FO Tatakoto Atoll
OC-299 V6 Yap East Group
OC-300 T31 McKean and Nikumaroro Atolls

SA-101 CE0 Juan Fernandez Archip (Alejandro Selkirk)
(0009484)
WA9PIE   
2019-12-02 00:24   
Going back to the post I made regarding the API key, I'm attaching the resulting json file.

We need to add this to the build script so that this is pulled and updated whenever we do a build. We just need to figure out how to ingest the json file as attached.

This replaces a file in resource called something like iota.xml.

Mike
(0009488)
WA9PIE   
2019-12-05 17:49   
(Last edited: 2019-12-05 17:50)
Basically, one of these things is what needs to happen:

Option 1:
- at the time of build, we hit this URL with this API key
- obtain the json file
- reformat it into the format currently in Logbook - OR modify Logbook to consume the json file directly
- add it into the build as a resource
- done

Option 2:
- we modify Logbook so that it can consume the json file directly
- we let Logbook update the IOTA file in a similar way as how the Country List gets updated now
- done
(this gets the updates to the users more quickly without the need for a new build; the downside is that it could expose our API key)

I'm not sure I have a preference. But option 2 has an added benefit.

Thoughts?

(0009579)
KB3NPH   
2020-02-04 05:58   
Ticket #672294 also indicates NA-249 missing from our current IOTA List.
(0009662)
PD9FER   
2020-04-08 05:45   
New Ticket #669380

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2315 [2 - Next Dev List (Holding Area)] Bug crash N/A 2018-01-26 06:45 2020-07-02 02:23
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing:
Summary: FT-891 Setting bandscope limits crashes HRD
Description: Set bandscope to 40m General class and the program dumps and closes.
Tags: FT-891, Yaesu
Steps To Reproduce: N/A
Additional Information: Ticket #364685
Minidump attached to ticked (also forwarded it to Roger)
Attached Files:
Notes
(0005117)
K7ZCZ   
2018-05-27 18:02   
This is the same crash as previously reported in the Olestra graphing component. We don't have support for that component at this time, so debugging issues surrounding it isn't feasible.

The call stack comes from a mouse move that's trying to call into the graphing control to change something about the data that it's graphing; that's about as much as I have for now. This stack seems like it's corrupted, since it recurs through functions that have no recurrence relationship.


Microsoft (R) Windows Debugger Version 10.0.15063.468 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\dumps\Mantis2315\HamRadioDeluxe_20180126_025346.mdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is: 
Windows 8.1 Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
6.3.9600.18217 (winblue_ltsb.160124-0053)
Machine Name:
Debug session time: Thu Jan 25 19:53:47.000 2018 (UTC - 7:00)
System Uptime: not available
Process Uptime: 0 days 0:00:09.000
................................................................
...............................
Loading unloaded module list
...........................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(2a60.26f8): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=09151040 ecx=00000000 edx=00000000 esi=09150ff8 edi=09151008
eip=778fd10c esp=00396954 ebp=00396960 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtGetContextThread+0xc:
778fd10c c20800          ret     8
0:000> .ecxr
Unable to load image C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\olch2d32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for olch2d32.dll
*** ERROR: Module load completed but symbols could not be loaded for olch2d32.dll
eax=04ebb020 ebx=00000020 ecx=00000000 edx=00000000 esi=00636378 edi=04deb020
eip=10021214 esp=00398568 ebp=003986d0 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
olch2d32+0x21214:
10021214 dd04cf          fld     qword ptr [edi+ecx*8] ds:002b:04deb020=????????????????
0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
00 003986d0 10020528 olch2d32+0x21214
*** WARNING: Unable to verify checksum for HamRadioDeluxe.exe
01 003987a0 00b81275 olch2d32+0x20528
02 00398824 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x00398848 {x=298 y=1})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
03 0039883c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 0, class CPoint point = {x=298 y=1})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
04 003988f8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n65834, long * pResult = 0x00398914)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
05 00398918 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
06 00398988 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
07 003989a8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
08 003989d4 771f90d1 user32!_InternalCallWinProc+0x2b
09 00398a68 771f932c user32!UserCallWinProcCheckWow+0x18e
0a 00398ac8 771f9529 user32!DispatchClientMessage+0xdc
0b 00398b08 77900666 user32!__fnDWORD+0x49
0c 00398b3c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
0d 00398ba8 77225190 user32!SendMessageWorker+0x2e7
0e 00398bc8 100449a1 user32!SendMessageA+0x50
0f 00398c24 77909510 olch2d32+0x449a1
10 00398cb4 771f8fce ntdll!RtlActivateActivationContextUnsafeFast+0x70
11 00398d04 77204d95 user32!UserCallWinProcCheckWow+0xa6
12 00398d40 00d09299 user32!CallWindowProcW+0x8d
13 00398d60 00d0c6f0 HamRadioDeluxe!CWnd::DefWindowProcW(unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116] 
14 00398d7c 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095] 
15 00398dec 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x00000200, struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
16 00398e0c 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n65834)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
17 00398e38 771f90d1 user32!_InternalCallWinProc+0x2b
18 00398ecc 771fa66f user32!UserCallWinProcCheckWow+0x18e
19 00398f38 772243bf user32!DispatchMessageWorker+0x208
1a 00398f80 77214fcd user32!DialogBox2+0x17e
1b 00398fb0 7721f907 user32!InternalDialogBox+0x107
1c 0039907c 7721f06d user32!SoftModalMessageBox+0xe2c
1d 003991e0 7726786b user32!MessageBoxWorker+0x293
1e 00399260 7726763b user32!MessageBoxTimeoutW+0x6b
1f 00399280 772678a8 user32!MessageBoxExW+0x1b
20 0039929c 00cff685 user32!MessageBoxW+0x18
21 00399a74 7753f515 HamRadioDeluxe!CHRDMiniDumper::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS * pExceptionPointers = 0x00399b20)+0x125 [c:\ham radio\hrdcommon\hrdminidumper.cpp @ 263] 
22 00399afc 77972df3 KERNELBASE!UnhandledExceptionFilter+0x165
23 00399ba0 779005d6 ntdll!LdrpLogFatalUserCallbackException+0x4d
24 00399bac 778fff41 ntdll!KiUserCallbackExceptionHandler+0x26
25 00399bd0 778fff13 ntdll!ExecuteHandler2+0x26
26 00399c9c 7790068f ntdll!ExecuteHandler+0x24
27 00399c9c 10021214 ntdll!KiUserExceptionDispatcher+0xf
28 0039a2d0 10020528 olch2d32+0x21214
29 0039a3a0 00b81275 olch2d32+0x20528
2a 0039a424 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x0039a448 {x=771 y=114})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
2b 0039a43c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 0, class CPoint point = {x=771 y=114})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
2c 0039a4f8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n7471875, long * pResult = 0x0039a514)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
2d 0039a518 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
2e 0039a588 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
2f 0039a5a8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
30 0039a5d4 771f90d1 user32!_InternalCallWinProc+0x2b
31 0039a668 771f932c user32!UserCallWinProcCheckWow+0x18e
32 0039a6c8 771f9529 user32!DispatchClientMessage+0xdc
33 0039a708 77900666 user32!__fnDWORD+0x49
34 0039a73c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
35 0039a7a8 77225190 user32!SendMessageWorker+0x2e7
36 0039a7c8 100449a1 user32!SendMessageA+0x50
37 0039a824 77909510 olch2d32+0x449a1
38 0039a8b4 771f8fce ntdll!RtlActivateActivationContextUnsafeFast+0x70
39 0039a904 77204d95 user32!UserCallWinProcCheckWow+0xa6
3a 0039a940 00d09299 user32!CallWindowProcW+0x8d
3b 0039a960 00d0c6f0 HamRadioDeluxe!CWnd::DefWindowProcW(unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116] 
3c 0039a97c 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095] 
3d 0039a9ec 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x00000200, struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
3e 0039aa0c 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
3f 0039aa38 771f90d1 user32!_InternalCallWinProc+0x2b
40 0039aacc 771fa66f user32!UserCallWinProcCheckWow+0x18e
41 0039ab38 772243bf user32!DispatchMessageWorker+0x208
42 0039ab80 77214fcd user32!DialogBox2+0x17e
43 0039abb0 7721f907 user32!InternalDialogBox+0x107
44 0039ac7c 7721f06d user32!SoftModalMessageBox+0xe2c
45 0039ade0 7726786b user32!MessageBoxWorker+0x293
46 0039ae60 7726763b user32!MessageBoxTimeoutW+0x6b
47 0039ae80 772678a8 user32!MessageBoxExW+0x1b
48 0039ae9c 00cff685 user32!MessageBoxW+0x18
49 0039b674 7753f515 HamRadioDeluxe!CHRDMiniDumper::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS * pExceptionPointers = 0x0039b720)+0x125 [c:\ham radio\hrdcommon\hrdminidumper.cpp @ 263] 
4a 0039b6fc 77972df3 KERNELBASE!UnhandledExceptionFilter+0x165
4b 0039b7a0 779005d6 ntdll!LdrpLogFatalUserCallbackException+0x4d
4c 0039b7ac 778fff41 ntdll!KiUserCallbackExceptionHandler+0x26
4d 0039b7d0 778fff13 ntdll!ExecuteHandler2+0x26
4e 0039b89c 7790068f ntdll!ExecuteHandler+0x24
4f 0039b89c 10021214 ntdll!KiUserExceptionDispatcher+0xf
50 0039bed0 10020528 olch2d32+0x21214
51 0039bfa0 00b81275 olch2d32+0x20528
52 0039c024 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x0039c048 {x=771 y=114})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
53 0039c03c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 0, class CPoint point = {x=771 y=114})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
54 0039c0f8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n7471875, long * pResult = 0x0039c114)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
55 0039c118 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
56 0039c188 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
57 0039c1a8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
58 0039c1d4 771f90d1 user32!_InternalCallWinProc+0x2b
59 0039c268 771f932c user32!UserCallWinProcCheckWow+0x18e
5a 0039c2c8 771f9529 user32!DispatchClientMessage+0xdc
5b 0039c308 77900666 user32!__fnDWORD+0x49
5c 0039c33c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
5d 0039c3a8 77225190 user32!SendMessageWorker+0x2e7
5e 0039c3c8 100449a1 user32!SendMessageA+0x50
5f 0039c424 77909510 olch2d32+0x449a1
60 0039c4b4 771f8fce ntdll!RtlActivateActivationContextUnsafeFast+0x70
61 0039c504 77204d95 user32!UserCallWinProcCheckWow+0xa6
62 0039c540 00d09299 user32!CallWindowProcW+0x8d
63 0039c560 00d0c6f0 HamRadioDeluxe!CWnd::DefWindowProcW(unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116] 
64 0039c57c 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095] 
65 0039c5ec 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x00000200, struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
66 0039c60c 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 0, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
67 0039c638 771f90d1 user32!_InternalCallWinProc+0x2b
68 0039c6cc 771fa66f user32!UserCallWinProcCheckWow+0x18e
69 0039c738 772243bf user32!DispatchMessageWorker+0x208
6a 0039c780 77214fcd user32!DialogBox2+0x17e
6b 0039c7b0 7721f907 user32!InternalDialogBox+0x107
6c 0039c87c 7721f06d user32!SoftModalMessageBox+0xe2c
6d 0039c9e0 7726786b user32!MessageBoxWorker+0x293
6e 0039ca60 7726763b user32!MessageBoxTimeoutW+0x6b
6f 0039ca80 772678a8 user32!MessageBoxExW+0x1b
70 0039ca9c 00cff685 user32!MessageBoxW+0x18
71 0039d274 7753f515 HamRadioDeluxe!CHRDMiniDumper::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS * pExceptionPointers = 0x0039d320)+0x125 [c:\ham radio\hrdcommon\hrdminidumper.cpp @ 263] 
72 0039d2fc 77972df3 KERNELBASE!UnhandledExceptionFilter+0x165
73 0039d3a0 779005d6 ntdll!LdrpLogFatalUserCallbackException+0x4d
74 0039d3ac 778fff41 ntdll!KiUserCallbackExceptionHandler+0x26
75 0039d3d0 778fff13 ntdll!ExecuteHandler2+0x26
76 0039d49c 7790068f ntdll!ExecuteHandler+0x24
77 0039d49c 10021214 ntdll!KiUserExceptionDispatcher+0xf
78 0039dad0 10020528 olch2d32+0x21214
79 0039dba0 00b81275 olch2d32+0x20528
7a 0039dc24 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x0039dc48 {x=771 y=114})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
7b 0039dc3c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 1, class CPoint point = {x=771 y=114})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
7c 0039dcf8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 1, long lParam = 0n7471875, long * pResult = 0x0039dd14)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
7d 0039dd18 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
7e 0039dd88 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
7f 0039dda8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
80 0039ddd4 771f90d1 user32!_InternalCallWinProc+0x2b
81 0039de68 771f932c user32!UserCallWinProcCheckWow+0x18e
82 0039dec8 771f9529 user32!DispatchClientMessage+0xdc
83 0039df08 77900666 user32!__fnDWORD+0x49
84 0039df3c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
85 0039dfa8 77225190 user32!SendMessageWorker+0x2e7
86 0039dfc8 100449a1 user32!SendMessageA+0x50
87 0039e024 77909510 olch2d32+0x449a1
88 0039e0b4 771f8fce ntdll!RtlActivateActivationContextUnsafeFast+0x70
89 0039e104 77204d95 user32!UserCallWinProcCheckWow+0xa6
8a 0039e140 00d09299 user32!CallWindowProcW+0x8d
8b 0039e160 00d0c6f0 HamRadioDeluxe!CWnd::DefWindowProcW(unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116] 
8c 0039e17c 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095] 
8d 0039e1ec 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x00000200, struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
8e 0039e20c 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
8f 0039e238 771f90d1 user32!_InternalCallWinProc+0x2b
90 0039e2cc 771fa66f user32!UserCallWinProcCheckWow+0x18e
91 0039e338 772243bf user32!DispatchMessageWorker+0x208
92 0039e380 77214fcd user32!DialogBox2+0x17e
93 0039e3b0 7721f907 user32!InternalDialogBox+0x107
94 0039e47c 7721f06d user32!SoftModalMessageBox+0xe2c
95 0039e5e0 7726786b user32!MessageBoxWorker+0x293
96 0039e660 7726763b user32!MessageBoxTimeoutW+0x6b
97 0039e680 772678a8 user32!MessageBoxExW+0x1b
98 0039e69c 00cff685 user32!MessageBoxW+0x18
99 0039ee74 7753f515 HamRadioDeluxe!CHRDMiniDumper::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS * pExceptionPointers = 0x0039ef20)+0x125 [c:\ham radio\hrdcommon\hrdminidumper.cpp @ 263] 
9a 0039eefc 77972df3 KERNELBASE!UnhandledExceptionFilter+0x165
9b 0039efa0 779005d6 ntdll!LdrpLogFatalUserCallbackException+0x4d
9c 0039efac 778fff41 ntdll!KiUserCallbackExceptionHandler+0x26
9d 0039efd0 778fff13 ntdll!ExecuteHandler2+0x26
9e 0039f09c 7790068f ntdll!ExecuteHandler+0x24
9f 0039f09c 10021214 ntdll!KiUserExceptionDispatcher+0xf
a0 0039f6d0 10020528 olch2d32+0x21214
a1 0039f7a0 00b81275 olch2d32+0x20528
a2 0039f824 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x0039f848 {x=771 y=114})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
a3 0039f83c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 1, class CPoint point = {x=771 y=114})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
a4 0039f8f8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 1, long lParam = 0n7471875, long * pResult = 0x0039f914)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
a5 0039f918 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
a6 0039f988 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
a7 0039f9a8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
a8 0039f9d4 771f90d1 user32!_InternalCallWinProc+0x2b
a9 0039fa68 771f932c user32!UserCallWinProcCheckWow+0x18e
aa 0039fac8 771f9529 user32!DispatchClientMessage+0xdc
ab 0039fb08 77900666 user32!__fnDWORD+0x49
ac 0039fb3c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
ad 0039fba8 77225190 user32!SendMessageWorker+0x2e7
ae 0039fbc8 100449a1 user32!SendMessageA+0x50
af 0039fc24 77909510 olch2d32+0x449a1
b0 0039fcb4 771f8fce ntdll!RtlActivateActivationContextUnsafeFast+0x70
b1 0039fd04 77204d95 user32!UserCallWinProcCheckWow+0xa6
b2 0039fd40 00d09299 user32!CallWindowProcW+0x8d
b3 0039fd60 00d0c6f0 HamRadioDeluxe!CWnd::DefWindowProcW(unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116] 
b4 0039fd7c 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095] 
b5 0039fdec 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x00000200, struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
b6 0039fe0c 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x0030050e, unsigned int nMsg = 0x200, unsigned int wParam = 1, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
b7 0039fe38 771f90d1 user32!_InternalCallWinProc+0x2b
b8 0039fecc 771fa66f user32!UserCallWinProcCheckWow+0x18e
b9 0039ff38 772243bf user32!DispatchMessageWorker+0x208
ba 0039ff80 77214fcd user32!DialogBox2+0x17e
bb 0039ffb0 7721f907 user32!InternalDialogBox+0x107
bc 003a007c 7721f06d user32!SoftModalMessageBox+0xe2c
bd 003a01e0 7726786b user32!MessageBoxWorker+0x293
be 003a0260 7726763b user32!MessageBoxTimeoutW+0x6b
bf 003a0280 772678a8 user32!MessageBoxExW+0x1b
c0 003a029c 00cff685 user32!MessageBoxW+0x18
c1 003a0a74 7753f515 HamRadioDeluxe!CHRDMiniDumper::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS * pExceptionPointers = 0x003a0b20)+0x125 [c:\ham radio\hrdcommon\hrdminidumper.cpp @ 263] 
c2 003a0afc 77972df3 KERNELBASE!UnhandledExceptionFilter+0x165
c3 003a0ba0 779005d6 ntdll!LdrpLogFatalUserCallbackException+0x4d
c4 003a0bac 778fff41 ntdll!KiUserCallbackExceptionHandler+0x26
c5 003a0bd0 778fff13 ntdll!ExecuteHandler2+0x26
c6 003a0c9c 7790068f ntdll!ExecuteHandler+0x24
c7 003a0c9c 10021214 ntdll!KiUserExceptionDispatcher+0xf
c8 003a12d0 10020528 olch2d32+0x21214
c9 003a13a0 00b81275 olch2d32+0x20528
ca 003a1424 00b81183 HamRadioDeluxe!CBandscopeDlg::SelectFrequency(class CPoint * point = 0x003a1448 {x=771 y=114})+0xd5 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1092] 
cb 003a143c 00d0b3e8 HamRadioDeluxe!CBandscopeDlg::OnMouseMove(unsigned int nFlags = 1, class CPoint point = {x=771 y=114})+0x13 [c:\ham radio\hamradiodeluxe\bandscopedlg.cpp @ 1042] 
cc 003a14f8 00d0c6d9 HamRadioDeluxe!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 1, long lParam = 0n7471875, long * pResult = 0x003a1514)+0x503 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2473] 
cd 003a1518 00d07cfe HamRadioDeluxe!CWnd::WindowProc(unsigned int message = 0x201, unsigned int wParam = 1, long lParam = 0n7471875)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
ce 003a1588 00d084b3 HamRadioDeluxe!AfxCallWndProc(class CWnd * pWnd = 0x03c8f604 {hWnd={...}}, struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x201, unsigned int wParam = 1, long lParam = 0n7471875)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
cf 003a15a8 771f8e71 HamRadioDeluxe!AfxWndProc(struct HWND__ * hWnd = 0x002a0544, unsigned int nMsg = 0x201, unsigned int wParam = 1, long lParam = 0n7471875)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
d0 003a15d4 771f90d1 user32!_InternalCallWinProc+0x2b
d1 003a1668 771f932c user32!UserCallWinProcCheckWow+0x18e
d2 003a16c8 771f9529 user32!DispatchClientMessage+0xdc
d3 003a1708 77900666 user32!__fnDWORD+0x49
d4 003a173c 771fe75e ntdll!KiUserCallbackDispatcher+0x36
d5 003a17a8 77225190 user32!SendMessageWorker+0x2e7
d6 003a17c8 100449c6 user32!SendMessageA+0x50
d7 00000000 00000000 olch2d32+0x449c6

(0005118)
K7ZCZ   
2018-05-27 19:04   
I have added Mantis0002315.7z to the dumps folder; for some reason, it was not available there.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2161 [2 - Next Dev List (Holding Area)] Bug tweak always 2017-07-26 16:08 2020-07-02 02:23
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing:
Summary: Radio type displayed in Display Radio screen in logbook not allways correct
Description: User comment:
using an FT-840 but showing FT-900
Tags:
Steps To Reproduce: Logbook... > View > Radio Screen > Display
Additional Information: https://support.ham-radio-deluxe.com/scp/tickets.php?id=10827
Attached Files:
Notes
(0004018)
K7ZCZ   
2017-08-17 23:07   
In RadioOptions, there is a table of radios which "work alike". In this table, for example, RADIO_FT840 is mapped to RADIO_FT900. My guess is that this issue is caused by the user working an FT-840, the code functionally mapping that radio to an FT-900, and subsequently reporting that the name of the actual radio is the FT-900.

It'll take a bit of digging to figure out where this happens, and a bit of work to split the "display" name from the "functional" name.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3017 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-02 21:46 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.5.0.164  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Rig Control
Testing: Not Started
Summary: Redundant commands sent to rig when selecting spots in Logbook's DX cluster contributes to performance issues
Description: When in Logbook, selecting a DX spot causes a redundant and unnecessary command to be sent to the rig. It should be eliminated to improve the overall performance of the software.

What seems to happen is this...

When you click on a spot, the software sends THREE commands to the radio - (a) set frequency, (b) set mode, and again (c) set frequency.

What should happen is that the software should send TWO commands to the radio - (a) set mode and then (b) set frequency.

Mode should always come first when changing mode because - when sent last, there is a frequency offset caused on most rigs when the mode is changed.

So you will see this when clicking on a spot changes the mode. When clicking on the spot is for the same mode... the redundant command is transparent (but still happens).
Tags:
Steps To Reproduce: I did this most recently with an FT-991A connected. But I've seen this with an FT-857D and an FTDX-5000. This could likely be happening with all radios. So begin by connecting Rig Control with one of these radios. It's probably best to use the slowest CAT baud rate so that the appearance of this is easier to observe.

Launch Rig Control connected to a radio as mentioned above
Launch Logbook and connect to a cluster node (such as the WA9PIE-2 node... but it really doesn't matter)
Set the rig to USB or LSB
Find a spot in cluster pane that is a CW spot and select it (with double-click, let's say)

Observe that the rig changes frequency... then mode... then frequency.

What should happen is that the rig should change mode... then frequency.

(the procedure above is a method to observe this... but it happens every single time a spot is selected from Logbook; I just don't know if it happens for every single manufacturer and/or rig)
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2256 [2 - Next Dev List (Holding Area)] Bug crash always 2017-09-21 08:07 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Functional
Testing: Not Started
Summary: Sat Tracker goes non-responsive
Description: Also follow-up via phone contact 398779

This is a fresh new installation of the software (just got it yesterday). I have configured Rotor, etc. Upon launching Sat Tracking, selecting satellite, and in the Tuning Dial; RX/TX, Manual....well, not even checking any of these...the Sat Tracking (Not Responding)....running this program with Admin Right does not do any good.

PS: Main reason for purchasing the software was for tracking satellites

Please send me a schedule date / time to troubleshoot this issue. Thanks in advance
Tags:
Steps To Reproduce: Mike, this is the issue I discussed with you a few days ago.

Did phone follow-up on this issue after Ferry had installed the BETA release which had the mini-dump code in it. Mini-dump was never created during lock-ups of Satellite Tracker. I worked with customer felt we had the problem resolved, however, after further testing customer reported via the follow-up that the fixes I attempted did not totally resolve the issue.

Customer claims to be an IT guy with a software company and is familiar with Windows 10. In the OSTicket #398779 follow-up ticket, customer did a crash-dump from Windows 10 and attached it to the ticket. This might be of some assistance in troubleshooting this issue. If you need me to pull this crash-dump from the ticket and forward it to you, let me know, otherwise, maybe you can just go to the support ticket 398779 and access the dump from there.
Additional Information: OSTicket: 531212
Attached Files:
Notes
(0004258)
K7ZCZ   
2017-09-22 14:12   

Sorry, Tim; I don't find minidump files at the OS Ticket entries you've linked.

Ticket 398779 has SatTrack_crashes.zip, an archive which contains a few screen shots in PNG format, but no minidump files.
Ticket 531212 is related, I think; it doesn't appear to have any files attached to it.

Minidump files end with the extension *.DMP or *.MDMP.

(0004571)
K7ZCZ   
2018-03-25 16:36   
needs a minidump file
(0006539)
WA9PIE   
2018-12-06 15:44   
We need to contact the user(s) who reported this and retest... and collect more info... or kill it because it can't be reproduced.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1498 [2 - Next Dev List (Holding Area)] Bug minor N/A 2013-12-23 21:44 2020-07-02 02:22
Reporter: Support Platform: Intel i7  
Assigned To: OS: Windows 7  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: ALE Window
Testing:
Summary: DM780 - ALE frequency offset
Description: There is an inconsistency is the updating of the frequency in ALE. For example,
using PSK31 on 15 meters, the radio is tuned to a nominal 21.070 MHz. This
frequency is reflected in the DM780 ALE screen. When I click on a signal on the
waterfall display, there is a 50% chance the the frequency will be properly
updated to reflect base + offset. As often as not, however, the frequency will
not update and remain on the base.

Sometimes a double click will resolve, sometimes it will not.
Tags:
Steps To Reproduce: Load DM780.
Under options, verify that Logbook, Appearance, Frequency, Radio+Offset is
selected.
Tune radio to a PSK31 base frequency.
Open the ALE window.

[loop]
Select a QSO on the waterfall.
Frequency may or may not update.
[repeat loop]
Additional Information: Reported by k2dls
Attached Files:
Notes
(0000111)
WA9PIE   
2014-01-19 21:06   
User replies:

While the fqy + offset is set correctly upon clicking a waterfall position, entering the callsign in ALE will change the frequency back to the radio fqy without offset. Therefore please keep this ticket open.
(0005453)
g3ucq   
2018-06-24 15:22   
The frequency changes when a call sign is entered as reported.
(0005791)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0006097)
k2ie   
2018-09-06 15:18   
Bug still exists.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1382 [2 - Next Dev List (Holding Area)] Bug crash N/A 2013-12-23 21:44 2020-07-02 02:22
Reporter: Support Platform: ZT i7 8 way VT Intell  
Assigned To: OS: Win  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing:
Summary: Bandscanner runs for awhile and crashes HRD
Description: We have had problems with this in 5.2, 6.0.103 has same problem. You open the
band scanner, say on 75M just let it run for 24 hrs and it crashes HRD DM. I
have tested this on TS-2000X, K3/100, FT-900 with same result. The other
related issue is when win 8 has task bar verticle on the left and you move the
HRD panel to the right this makes the problem happen much sooner. So
re-size/move are impacting this as well.
Tags: Kenwood, TS-2000
Steps To Reproduce: Connect to TS-2000X or K3/100 or FT-900
Select HF band 75M in this example.
Open Band scanner
Leave it running over night

2nd test case
move Win8 task bar to left verticule position
repeat above usually in hour or so same problem emerges
Additional Information: Reported by JBIRDLEBOUGH

I am still testing base features, will submit more reports once we find issues
and will continue to check other bugs first before submitting.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
533 [2 - Next Dev List (Holding Area)] Bug major always 2013-12-21 18:56 2020-07-02 02:22
Reporter: W4PC Platform:  
Assigned To: OS: Windows 7 64bit  
Priority: high OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing:
Summary: DM780 Stop CW = No PTT next time
Description: Short version: Hitting F4 Stop in CW mode will prevent PTT from being triggered properly next time.

I showed Rick this bug at Dayton, he asked me to log it.

This issue has been around for a few releases, and its still there in the current version.

DM780 6.1.2.181
RigExpert TI-5 to FTdx5000MP (rig and interface doesn't matter).
Other interfaces will also show the problem.

It's just handy to use the RigExpert as it has an LED for CW and one for PTT. Makes it easy to see the problem.
Tags:
Steps To Reproduce: In DM780, CW mode, put in something you want to send in the text window e.g.
W4PC de VE3MSC k

Just above that hit Send (F1).
PTT will come on solid, CW will blink w the code.
Part way through, before it finishes, hit Stop (F4).
PTT off, CW off.

Now, hit Send or hit mark all text as sent (tx with arrow icon).
PTT may flash on for an instant, but will go off.
CW will blink w code as normal.
PTT should have stayed on, but it doesn't!

Basically, if you've ever hit the STOP, DM780 wont trigger PTT properly again.
You can exit the program and relaunch DM780 to get this to work again.
Additional Information: If you need to know, in the program options:
Modes+IDs: CW - Use PTT [x] [x] enable serial port keying, COM2, DTR.
PTT: PTT is via serial port COM2 on my setup, RTS.

Depending on your rig, e.g. Yaesu FT5000, putting rig in full break in mode may allow things to work, as key down will trigger transmit. However, if this mode is off, it won't work.

I tried to put in 6.1.2.181 but its not an option for the Report Build below.
Also wasn't sure if I've cataloged this in right sub-module.
Attached Files:
Notes
(0000324)
WA9PIE   
2014-02-02 16:41   
All have been viewed and checked-in.
(0005416)
g3ucq   
2018-06-24 03:35   
Using my Icom IC-7610 I entered text in the Send window. Clicked F4 to send and part way through clicked F4 to Stop. Clicking F4 again continues sending from where the the transmission was stopped so works OK for me. However, no characters are actually transmitted. I tried setting DTR and RTS to On and Off but that may no difference..

Mode CW (Ky Cmd) does work but clicking F5 to stop the transmission does not Stop the transmission. Esc does not stop either. Transmission continues to the end of the characters.
(0005810)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0005823)
g3ucq   
2018-07-25 14:09   
Using CW (SSB) with my IC-7610 send CW with no problems.
Esc stops the sending after a while.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3355 [2 - Next Dev List (Holding Area)] Maintenance minor have not tried 2019-06-15 18:18 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Eliminate the limit of 10 locations per callsign in My Station
Description: I don't have a whole lot of information about this. I've never reached the limit of 10 myself.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008091)
WA9PIE   
2019-06-16 00:25   
In the 6.6.0.231 beta build, I went through the process of adding 10 locations. The limit is actually better described as "HOME" location + 10 more... for a total of 11.

I can confirm that this limit exists. It should be removed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3348 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2019-06-12 10:40 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Add callsign lookup button to make it easier to populate the My Station dialog
Description: Let's add a "Callsign Lookup" button to the My Station dialog box to make it easier for customers to populate the location content.

I'll post a picture of this change after we get Mantis fixed (so attachments can be added).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3236 [2 - Next Dev List (Holding Area)] Maintenance tweak always 2019-03-06 11:22 2020-07-02 02:22
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Mapper
Sub-Module: (select)
Testing: Not Started
Summary: Mapper Splash Screen
Description: When opening Mapper, the Splash Screen refers to Simon Brown and Peter Halpin
Tags:
Steps To Reproduce: Open Mapper and notice that the Splash Screen refers to Simon Brown and Peter Halpin.
Also the version number may be out of date.
Additional Information:
System Description
Attached Files:
Notes
(0007610)
WA9PIE   
2019-03-06 22:23   
Confirmed... good catch John.
(0007614)
K7ZCZ   
2019-03-06 22:41   
What should it say, instead? New graphic? Sometihng else?
(0008104)
WA9PIE   
2019-06-16 17:17   
Can you send me a copy of that splash screen so I can get a new one designed?

(Is the text embedded in the image?)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3201 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2019-02-28 01:39 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Add capability of one QSO existing in multiple grids and update VUCC awards program
Description: An often requested feature, also a efficiency we have compared to other logging programs, is to enable a single QSO to be conducted from multiple grids.

The ADIF standards committee has provided new fields to facilitate this as follows:

GRIDSQUARE and MY_GRIDSQUARE are for a single 2, 4, 6, or 8 character locator only. (I believe I remember reading that RSGB/IARU were formally defining 10 character locators, so perhaps at some stage the definition should be extended.)

VUCC_GRIDS and MY_VUCC_GRIDS can contain either 2 or 4 comma-separated locators.
In this case, each locator must be exactly 4 characters long, being specifically for use with the ARRL’s VUCC awards.

At minimum, we'll need to add these two (VUCC) fields and re-code the awards module to enable it to conform to the comma separated format of these fields.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3173 [2 - Next Dev List (Holding Area)] Bug major always 2019-02-11 11:21 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Radio Support
Testing: Not Started
Summary: Satellite Tracker not showing VFO-B in Radio Pane
Description: Ticket #150800 - Customer is complaining that the Satellite Tracker is not showing nor controlling VFO-B in his FT-847 radio.

Nothing really to replicate unless you have an FT-847 available, in which case, Run Ham Radio Deluxe. and connect to an FT-847 radio. Open Satellite Tracker and connect the Radio Pane to Rig Control by clicking the "Connect" button on the top of the Radio Control Pane in Sat. Track.

An image of the bug is attached.
Tags: FT-847, Yaesu
Steps To Reproduce:
Additional Information:
Attached Files: Click Connect on Radio Pane.jpg (218,412 bytes) 2019-02-11 11:21
https://development.hamradiodeluxe.com/file_download.php?file_id=686&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3133 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2019-01-29 00:58 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Add Elecraft K3S to Rig Control
Description: At the request of a customer (ticket #699831), we need to add the new Elecraft K3S.

Wayne at Elecraft advises the following:

"The K3 and the K3S have the same command set. But the K3S has an extra preamp setting (PA cmd) and an extra attenuator setting (RA)."

So, potentially, it's possible to copy the K3 to an additional rig choice of K3S and add these two commands?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007143)
K7ZCZ   
2019-01-29 23:04   
A lot has been written about the simplicity of adding radios to Rig Control, and it's all incorrect. This is no exception.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3132 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2019-01-28 15:36 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Data
Testing: Not Started
Summary: Add NASA All to Satellite Tracking
Description: AMSAT customers have asked us to add the following file to the Kepler data download:

http://www.amsat.org/amsat/ftp/keps/current/nasa.all
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007126)
WA9PIE   
2019-01-29 14:33   
By way of one of the AMSAT guys, I was shown how to add this in the Satellite Tracking app. It works fine.

What I think we should do is (a) add the latest "nasa all" to the build (from URL above) and (b) we should probably have the build process refresh all these files when a build is cut.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3128 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-01-27 17:11 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: Need a way to distinguish satellite and non-satellite QSOs for DXCC 2m and Satellite award
Description: Thus far, I've tried to look at the satellite field and assume that when it's empty, it's not satellite... and when it is not empty, it is a satellite.

I'm not able to get this to work and I'll probably need some help with it.
Tags:
Steps To Reproduce: Add a 2m QSO in your log for any country
Look for it in awards...

Modify that QSO to put satellite AO-51 in for the satellite...
Look for it in awards...
Additional Information: The Satellite app has a list of satellites. Perhaps we could use that list in the dropdown to populated it in the ALE satellite tab. However, we still need a way to distinguish between them.
Attached Files:
Notes
(0007962)
K7ZCZ   
2019-05-30 16:53   
Switched to "enhnacement" per the team call on 2019-05-30

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3099 [2 - Next Dev List (Holding Area)] Enhancement minor N/A 2019-01-25 12:56 2020-07-02 02:22
Reporter: KC7FPF Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Implement buton access to Voice Recordings Playback Bank, 5 memories, using CAT Command PB Play Back
Description: Ticket 579817

Please implement button access to Voice Recordings Playback Bank, 5 memories, using CAT Command PB Play Back

Please assign each to it's own button.

Necessary for Contesting and DXing
Tags: IC-7300, ICOM
Steps To Reproduce:
Additional Information: This issue was resolved for the Yaesu FT991A Please reference Mantis 2630
Attached Files: dropdwon7300.JPG (126,791 bytes) 2019-01-25 12:56
https://development.hamradiodeluxe.com/file_download.php?file_id=656&type=bug
jpg

recorded for ic7300.JPG (41,449 bytes) 2019-01-29 08:45
https://development.hamradiodeluxe.com/file_download.php?file_id=664&type=bug
jpg
Notes
(0007082)
K7ZCZ   
2019-01-26 21:42   
Icom doesn't document a CI-V command for Voice recorder TX playback on this radio.

From an update to the ticket, it looks like the customer figured out that the IC-7610 command works on his IC-7300, and has programmed a macro button for the feature he wants.
(0007115)
KC7FPF   
2019-01-29 08:45   
figured it out! One of the CAT commands for the IC-7610 also works for the IC-7300. The specific command for playing the recording at memory T1 is:FE-FE-FE-94-E0-28-00-01-FD. For the recording at memory T2 the " -01- " gets changed to " -02-", and so on. Thanks for your assistance. Feel free to post this on the user forums.

Please see ticket 579817
(0007205)
K7ZCZ   
2019-02-01 16:03   
During the team call on 2019-01-31, we agreed that we were uncomfortable using undocumented radio commands in the application. We decided that MikeC would contact Icom to see if documentation exists for the voice playback control commands on the IC-7300. If Icom supports their use, we can implement this feature in the product. If not, we'll leavei t to customers to add the workaround at their discretion.
(0007286)
WA9PIE   
2019-02-05 22:29   
I have an inquiry in to Ray Novak and I'm awaiting his response.
(0007292)
K7ZCZ   
2019-02-06 11:21   
Marking this assigned, since it is actively being worked
(0007322)
WA9PIE   
2019-02-08 11:06   
I spoke to Ray here at Hamcation. Ray advises that this capability was added in the IC-7300 with a recent firmware update. ICOM does support this.

He tells me that it's documented in the Japanese version of the documentation and that they expect to update the English language documentation soon. But yes, it is supported... and they're the same commands used for the IC-7610.
(0007331)
K7ZCZ   
2019-02-08 14:39   
Oh! I should've thought of looking at the Japanese-language manual.

I can get this implemented ...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2907 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-09-27 11:19 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.886  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Investigate IC-7410 rig control commands
Description: A user reports the following:

"my ICOM IC-7410 has obvious errors with HRD.
For example (I don't remember which) changing the TX bass or TX treble will cause the screen to go dark.
There are other problems as well, but as a BSEE with 30+ years of experience, I can tell you this is a crap implementation."

We should investigate the commands for this radio (and the IC-7400).
Tags: IC-7410, ICOM
Steps To Reproduce: Changing the TX bass or TX treble and observe the results to the screen.
Additional Information: https://support.hamradiodeluxe.com/scp/tickets.php?id=20834
Attached Files:
Notes
(0007092)
WA9PIE   
2019-01-27 17:22   
I have been reporting this issue for over a year. Please see the attached email from you. I am also sending some pictures here. Also, the radio has only one firmware release, so it is running the latest and only firmware. The radio was reset to factory defaults and everything re-entered. It exhibits no issues other than when running with HRD.

Pic 1 – Shows the HRD version I am running: the latest. Although I didn’t see the 7410 mentioned in the release notes, I was hopeful.

Pic 2 – Shows my LCD backlight at 75% brightness

Note when I open HRD, it shows my TX Treble at 5. This is not correct, it is not reading the right register. The actual value in the radio is 0 (no treble boost). No picture.

Pic 3 – Shows that when I move the TX Treble slider all the way to minimum, the backlight on my radio goes dark.

The only way to recover it is through the radio menu.

Pic 4 – As the screen goes dark, the band-edge beep level is also reduced to minimum (from 50%). I had to first restore the back-light to show this on the radio.

Pic 5 – Shows the slider moved all the way to the left, which is what makes my screen dark and my beep-level go to minimum.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2798 [2 - Next Dev List (Holding Area)] Bug major always 2018-07-02 03:42 2020-07-02 02:22
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: The Date field in ALE can reverse DD/MM to MM/DD
Description: Using the Next/Prev buttons in the ALE window with a QSO open the Date field can revers the DD/MM to MM/YY
The day has to be less than 12 for this to happen.
Tags:
Steps To Reproduce: Open the Logbook ALE with a QSO with a Day date of 12 or more making sure that the Prev date is also 12 or more.
Press the Next button and the DD/MM stay as they were.
Now select a Day of 12 or less and repeat. The DD/MM swap.
My Windows 10 Date setting is DD/MM/YYYY.
Additional Information: This has been reported in the Peer Forum.
One customer contacted support and was told -
"This changing is strange. I checked with our programmers and they confirmed that the date format is 100% controlled by
the date format set in the Windows software. It would appear if the format was changing, it would have to be something in Windows that is causing the change and not something in HRD."
System Description
Attached Files:
Notes
(0005604)
K7ZCZ   
2018-07-03 19:45   
The forum thread in question is here: https://forums.hamradiodeluxe.com/node/46870

The ticket in question is here: https://support.hamradiodeluxe.com/scp/tickets.php?id=7867

It's simply false that "the date format is 100% controlled by the date format set in the Windows software." The logbook uses two different fixed formats itself internally, and converts between those two formats. It converts from those formats to the displayed format. The displayed format should be set by the user's preference in Windows, but it sometimes isn't. The conversion of formats is sometimes incorrect, and bugs like this are the result.

The conversions are not factored correctly. They're copied and pasted throughout the code, and certain bugs exist in certain places; but are fixed in others. Undoubtedly, there are compensating bugs in different places and false dependencies grown from that situation.

We can probably figure out exactly whre this specific format conversion is confused, but the correct ifx would be to get the logbook's code to internally use exactly one date/time representation. Then, convert to and from user formats in exactly one place.
(0005785)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0005822)
g3ucq   
2018-07-25 14:01   
No change
(0005829)
K7ZCZ   
2018-07-25 22:50   
No change was made to the code; there's nothing to test here. My notes above indicate that I evaluated the code and they suggest a solution. The solution hasn't yet been implemented.
(0007619)
g3ucq   
2019-03-07 04:45   
Not yet fixed.
(0007626)
K7ZCZ   
2019-03-07 08:39   
No change in behaviour is expected, as no change to the code has been made. Is a more reliable repro case available?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2686 [2 - Next Dev List (Holding Area)] Bug crash always 2018-04-19 12:31 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Random Crashes when clicking on stations in bandmap
Description: Customer reports random crashes with mini-dump when clicking on stations in his open bandmaps. This is something that has been happening since updating to V6.0.4.806. A mini-dump was generated and is in the
\Team Drives\HRD Software\Dumps\HRDLogbook_20180419_163134.mdmp

I was in a remote with the customer and witnessed the issue when the above mini-dump was created.
Tags:
Steps To Reproduce: Run HRD and Logbook as normal
Have DX Cluster open along with one or two bandmaps
Click on calls in bandmat to move them to the lookup window
If you keep clicking on calls, eventually the Logbook will crash with the minidump being created.

Additional Information: Ticket #329526
Attached Files: Mantis2686_HRDLogbok.7z (250,229 bytes) 2018-04-21 10:05
https://development.hamradiodeluxe.com/file_download.php?file_id=374&type=bug
Notes
(0004872)
K7ZCZ   
2018-04-21 10:05   
I've removed the dump file from Google Drive and renamed it; compressed it, too. It's attached to this issue so that it won't get lost.
(0004873)
K7ZCZ   
2018-04-21 10:08   
Dump looks like a stack overflow:


0:000> .ecxr
Unable to load image C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\HRDLogbook.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for HRDLogbook.exe
eax=002e2000 ebx=17274008 ecx=002e0c14 edx=00000000 esi=0000c337 edi=17274008
eip=014a5767 esp=002ed408 ebp=002ed420 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
HRDLogbook!_chkstk+0x27:
014a5767 8500            test    dword ptr [eax],eax  ds:002b:002e2000=00000000
0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 002ed420 0191e892 HRDLogbook!_chkstk(void)+0x27 [f:\dd\vctools\crt\crtw32\startup\i386\chkstk.asm @ 99] 
01 002ed434 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
02 002ed4ec 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x002ed524)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
03 002ed508 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x002ed524)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
04 002ed528 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
05 002ed598 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
06 002ed5b8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
07 002ed5e4 77396d3a user32!InternalCallWinProc+0x23
08 002ed65c 773a0d37 user32!UserCallWinProcCheckWow+0x109
09 002ed694 773a0d5d user32!CallWindowProcAorW+0xab
0a 002ed6b4 015e6bac user32!CallWindowProcW+0x1b
0b 002ed6fc 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
0c 002ed728 77396d3a user32!InternalCallWinProc+0x23
0d 002ed7a0 773977d3 user32!UserCallWinProcCheckWow+0x109
0e 002ed804 7739789a user32!DispatchMessageWorker+0x3cb
0f 002ed814 01367a80 user32!DispatchMessageW+0xf
10 002ed824 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
11 002fa040 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
12 002fa054 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
13 002fa10c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x002fa144)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
14 002fa128 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x002fa144)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
15 002fa148 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
16 002fa1b8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
17 002fa1d8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
18 002fa204 77396d3a user32!InternalCallWinProc+0x23
19 002fa27c 773a0d37 user32!UserCallWinProcCheckWow+0x109
1a 002fa2b4 773a0d5d user32!CallWindowProcAorW+0xab
1b 002fa2d4 015e6bac user32!CallWindowProcW+0x1b
1c 002fa31c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
1d 002fa348 77396d3a user32!InternalCallWinProc+0x23
1e 002fa3c0 773977d3 user32!UserCallWinProcCheckWow+0x109
1f 002fa424 7739789a user32!DispatchMessageWorker+0x3cb
20 002fa434 01367a80 user32!DispatchMessageW+0xf
21 002fa444 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
22 00306c60 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
23 00306c74 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
24 00306d2c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00306d64)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
25 00306d48 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00306d64)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
26 00306d68 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
27 00306dd8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
28 00306df8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
29 00306e24 77396d3a user32!InternalCallWinProc+0x23
2a 00306e9c 773a0d37 user32!UserCallWinProcCheckWow+0x109
2b 00306ed4 773a0d5d user32!CallWindowProcAorW+0xab
2c 00306ef4 015e6bac user32!CallWindowProcW+0x1b
2d 00306f3c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
2e 00306f68 77396d3a user32!InternalCallWinProc+0x23
2f 00306fe0 773977d3 user32!UserCallWinProcCheckWow+0x109
30 00307044 7739789a user32!DispatchMessageWorker+0x3cb
31 00307054 01367a80 user32!DispatchMessageW+0xf
32 00307064 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
33 00313880 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
34 00313894 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
35 0031394c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00313984)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
36 00313968 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00313984)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
37 00313988 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
38 003139f8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
39 00313a18 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
3a 00313a44 77396d3a user32!InternalCallWinProc+0x23
3b 00313abc 773a0d37 user32!UserCallWinProcCheckWow+0x109
3c 00313af4 773a0d5d user32!CallWindowProcAorW+0xab
3d 00313b14 015e6bac user32!CallWindowProcW+0x1b
3e 00313b5c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
3f 00313b88 77396d3a user32!InternalCallWinProc+0x23
40 00313c00 773977d3 user32!UserCallWinProcCheckWow+0x109
41 00313c64 7739789a user32!DispatchMessageWorker+0x3cb
42 00313c74 01367a80 user32!DispatchMessageW+0xf
43 00313c84 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
44 003204a0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
45 003204b4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
46 0032056c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003205a4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
47 00320588 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003205a4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
48 003205a8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
49 00320618 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
4a 00320638 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
4b 00320664 77396d3a user32!InternalCallWinProc+0x23
4c 003206dc 773a0d37 user32!UserCallWinProcCheckWow+0x109
4d 00320714 773a0d5d user32!CallWindowProcAorW+0xab
4e 00320734 015e6bac user32!CallWindowProcW+0x1b
4f 0032077c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
50 003207a8 77396d3a user32!InternalCallWinProc+0x23
51 00320820 773977d3 user32!UserCallWinProcCheckWow+0x109
52 00320884 7739789a user32!DispatchMessageWorker+0x3cb
53 00320894 01367a80 user32!DispatchMessageW+0xf
54 003208a4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
55 0032d0c0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
56 0032d0d4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
57 0032d18c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0032d1c4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
58 0032d1a8 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0032d1c4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
59 0032d1c8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
5a 0032d238 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
5b 0032d258 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
5c 0032d284 77396d3a user32!InternalCallWinProc+0x23
5d 0032d2fc 773a0d37 user32!UserCallWinProcCheckWow+0x109
5e 0032d334 773a0d5d user32!CallWindowProcAorW+0xab
5f 0032d354 015e6bac user32!CallWindowProcW+0x1b
60 0032d39c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
61 0032d3c8 77396d3a user32!InternalCallWinProc+0x23
62 0032d440 773977d3 user32!UserCallWinProcCheckWow+0x109
63 0032d4a4 7739789a user32!DispatchMessageWorker+0x3cb
64 0032d4b4 01367a80 user32!DispatchMessageW+0xf
65 0032d4c4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
66 00339ce0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
67 00339cf4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
68 00339dac 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00339de4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
69 00339dc8 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00339de4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
6a 00339de8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
6b 00339e58 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
6c 00339e78 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
6d 00339ea4 77396d3a user32!InternalCallWinProc+0x23
6e 00339f1c 773a0d37 user32!UserCallWinProcCheckWow+0x109
6f 00339f54 773a0d5d user32!CallWindowProcAorW+0xab
70 00339f74 015e6bac user32!CallWindowProcW+0x1b
71 00339fbc 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
72 00339fe8 77396d3a user32!InternalCallWinProc+0x23
73 0033a060 773977d3 user32!UserCallWinProcCheckWow+0x109
74 0033a0c4 7739789a user32!DispatchMessageWorker+0x3cb
75 0033a0d4 01367a80 user32!DispatchMessageW+0xf
76 0033a0e4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
77 00346900 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
78 00346914 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
79 003469cc 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00346a04)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
7a 003469e8 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00346a04)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
7b 00346a08 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
7c 00346a78 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
7d 00346a98 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
7e 00346ac4 77396d3a user32!InternalCallWinProc+0x23
7f 00346b3c 773a0d37 user32!UserCallWinProcCheckWow+0x109
80 00346b74 773a0d5d user32!CallWindowProcAorW+0xab
81 00346b94 015e6bac user32!CallWindowProcW+0x1b
82 00346bdc 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
83 00346c08 77396d3a user32!InternalCallWinProc+0x23
84 00346c80 773977d3 user32!UserCallWinProcCheckWow+0x109
85 00346ce4 7739789a user32!DispatchMessageWorker+0x3cb
86 00346cf4 01367a80 user32!DispatchMessageW+0xf
87 00346d04 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
88 00353520 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
89 00353534 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
8a 003535ec 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00353624)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
8b 00353608 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00353624)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
8c 00353628 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
8d 00353698 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
8e 003536b8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
8f 003536e4 77396d3a user32!InternalCallWinProc+0x23
90 0035375c 773a0d37 user32!UserCallWinProcCheckWow+0x109
91 00353794 773a0d5d user32!CallWindowProcAorW+0xab
92 003537b4 015e6bac user32!CallWindowProcW+0x1b
93 003537fc 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
94 00353828 77396d3a user32!InternalCallWinProc+0x23
95 003538a0 773977d3 user32!UserCallWinProcCheckWow+0x109
96 00353904 7739789a user32!DispatchMessageWorker+0x3cb
97 00353914 01367a80 user32!DispatchMessageW+0xf
98 00353924 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
99 00360140 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
9a 00360154 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
9b 0036020c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00360244)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
9c 00360228 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00360244)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
9d 00360248 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
9e 003602b8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
9f 003602d8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
a0 00360304 77396d3a user32!InternalCallWinProc+0x23
a1 0036037c 773a0d37 user32!UserCallWinProcCheckWow+0x109
a2 003603b4 773a0d5d user32!CallWindowProcAorW+0xab
a3 003603d4 015e6bac user32!CallWindowProcW+0x1b
a4 0036041c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
a5 00360448 77396d3a user32!InternalCallWinProc+0x23
a6 003604c0 773977d3 user32!UserCallWinProcCheckWow+0x109
a7 00360524 7739789a user32!DispatchMessageWorker+0x3cb
a8 00360534 01367a80 user32!DispatchMessageW+0xf
a9 00360544 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
aa 0036cd60 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
ab 0036cd74 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
ac 0036ce2c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0036ce64)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
ad 0036ce48 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0036ce64)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
ae 0036ce68 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
af 0036ced8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
b0 0036cef8 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
b1 0036cf24 77396d3a user32!InternalCallWinProc+0x23
b2 0036cf9c 773a0d37 user32!UserCallWinProcCheckWow+0x109
b3 0036cfd4 773a0d5d user32!CallWindowProcAorW+0xab
b4 0036cff4 015e6bac user32!CallWindowProcW+0x1b
b5 0036d03c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
b6 0036d068 77396d3a user32!InternalCallWinProc+0x23
b7 0036d0e0 773977d3 user32!UserCallWinProcCheckWow+0x109
b8 0036d144 7739789a user32!DispatchMessageWorker+0x3cb
b9 0036d154 01367a80 user32!DispatchMessageW+0xf
ba 0036d164 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
bb 00379980 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
bc 00379994 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
bd 00379a4c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00379a84)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
be 00379a68 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x00379a84)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
bf 00379a88 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
c0 00379af8 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
c1 00379b18 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
c2 00379b44 77396d3a user32!InternalCallWinProc+0x23
c3 00379bbc 773a0d37 user32!UserCallWinProcCheckWow+0x109
c4 00379bf4 773a0d5d user32!CallWindowProcAorW+0xab
c5 00379c14 015e6bac user32!CallWindowProcW+0x1b
c6 00379c5c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
c7 00379c88 77396d3a user32!InternalCallWinProc+0x23
c8 00379d00 773977d3 user32!UserCallWinProcCheckWow+0x109
c9 00379d64 7739789a user32!DispatchMessageWorker+0x3cb
ca 00379d74 01367a80 user32!DispatchMessageW+0xf
cb 00379d84 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
cc 003865a0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
cd 003865b4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
ce 0038666c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003866a4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
cf 00386688 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003866a4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
d0 003866a8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
d1 00386718 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
d2 00386738 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
d3 00386764 77396d3a user32!InternalCallWinProc+0x23
d4 003867dc 773a0d37 user32!UserCallWinProcCheckWow+0x109
d5 00386814 773a0d5d user32!CallWindowProcAorW+0xab
d6 00386834 015e6bac user32!CallWindowProcW+0x1b
d7 0038687c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
d8 003868a8 77396d3a user32!InternalCallWinProc+0x23
d9 00386920 773977d3 user32!UserCallWinProcCheckWow+0x109
da 00386984 7739789a user32!DispatchMessageWorker+0x3cb
db 00386994 01367a80 user32!DispatchMessageW+0xf
dc 003869a4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
dd 003931c0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
de 003931d4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
df 0039328c 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003932c4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
e0 003932a8 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x003932c4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
e1 003932c8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
e2 00393338 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
e3 00393358 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
e4 00393384 77396d3a user32!InternalCallWinProc+0x23
e5 003933fc 773a0d37 user32!UserCallWinProcCheckWow+0x109
e6 00393434 773a0d5d user32!CallWindowProcAorW+0xab
e7 00393454 015e6bac user32!CallWindowProcW+0x1b
e8 0039349c 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
e9 003934c8 77396d3a user32!InternalCallWinProc+0x23
ea 00393540 773977d3 user32!UserCallWinProcCheckWow+0x109
eb 003935a4 7739789a user32!DispatchMessageWorker+0x3cb
ec 003935b4 01367a80 user32!DispatchMessageW+0xf
ed 003935c4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
ee 0039fde0 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 
ef 0039fdf4 01361897 HRDLogbook!CLogbookFull::OnCall(unsigned int wParam = 0, long lParam = 0n78765876)+0x32 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 728] 
f0 0039feac 0132d896 HRDLogbook!CWnd::OnWndMsg(unsigned int message = <Value unavailable error>, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0039fee4)+0x77b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2679] 
f1 0039fec8 013629bc HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876, long * pResult = 0x0039fee4)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
f2 0039fee8 0135e3ae HRDLogbook!CWnd::WindowProc(unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
f3 0039ff58 0135eb63 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x17274008 {hWnd={...}}, struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
f4 0039ff78 773962fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0007078c, unsigned int nMsg = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
f5 0039ffa4 77396d3a user32!InternalCallWinProc+0x23
f6 003a001c 773a0d37 user32!UserCallWinProcCheckWow+0x109
f7 003a0054 773a0d5d user32!CallWindowProcAorW+0xab
f8 003a0074 015e6bac user32!CallWindowProcW+0x1b
f9 003a00bc 773962fa HRDLogbook!CXTPHookManager::HookWndProc(struct HWND__ * hWnd = 0x0135eb2f, unsigned int message = 0xc337, unsigned int wParam = 0, long lParam = 0n78765876)+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
fa 003a00e8 77396d3a user32!InternalCallWinProc+0x23
fb 003a0160 773977d3 user32!UserCallWinProcCheckWow+0x109
fc 003a01c4 7739789a user32!DispatchMessageWorker+0x3cb
fd 003a01d4 01367a80 user32!DispatchMessageW+0xf
fe 003a01e4 01923092 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
ff 003aca00 0191e892 HRDLogbook!CLogbookFull::CallsignLookup(wchar_t * lpCallsign = 0x04b1df34 "9K2BS", CLogbookFull::eCallsignLookup eContext = LOOKUP_NEW_CALL (0n3))+0x132 [c:\ham radio\logbook\hrdlogbook\logbookfulllookup.cpp @ 882] 



(0004874)
K7ZCZ   
2018-04-21 10:23   
Except it's not quite that simple, of course. The CallsignLookup() function sends a message to do the lookup. It then waits for some flags to move around so it knows the lookup work is done. Per the usual paradigm in this code, it sits around and pumps its own messages. In this case, it does so with two nested loops:

    if( m_bCallsignLookupBusy )
    {
         // Process messages
        DWORD dwTimeout = GetTickCount()+5000;
        MSG msg;
        while( m_bCallsignLookupBusy && (dwTimeout > GetTickCount()) )
        {
            while( m_bCallsignLookupBusy && PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) )
            {
                if( m_bResetting || m_bCallsignLookupCancel ) return;
                if( msg.message == WM_QUIT ) return;
                theApp.PumpMessage();
            }
        }
    }
    m_bCallsignLookupBusy = TRUE;


This is obviously a terrible design; the problem is that it usually works. When it doesn't work, we have the case demonstrated by this bug -- where one of the messages in the queue is our own registered nLibMsgCall message that invokes the lookup handler. This loop retreives that message without removing it, then calls the application's PumpMessage() method to process it, which essentially repeats the message invocation. The invocation, of course, calls the message handler, which enters the pump, which pumps the message again, which ...

It would seem that the code is written to pump messages until some message is found (and processed) which resets the m_bCallsignLookupBusy flag and causes these loops to exit.

Problem is, the m_bCallsignLookupBusy flag is used all over this code to shuffle messages around and try to avoid who knows what side-effects of this woefully flawed architecture. An effort to unwind the problem will be very invovled, so I have to resort to figuring out of there's some sort of partial fix that can be applied to sort out this issue. That'll result in playing whack-a-mole with other problems that pop-up because of whatever assumptions are made about the interaction and ordering of messages in this part of the code.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2139 [2 - Next Dev List (Holding Area)] Bug minor random 2017-07-18 13:58 2020-07-02 02:22
Reporter: PD9FER Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Rig Control
Testing: Not Started
Summary: Satellite tracking with multiple radio's not working as expected
Description: I have a hard time explaining this, so I do a paste from the customers ticket:

For my satellite operations I use HRD to control two FT-991's, one uplink, one downlink. When doing so there is big problem. The frequency control of the radio designated as VFO B is relatively aligned with the Doppler shift changes in the program. However, the same cannot be said for VFO A. There is a great time lag between the changing frequency of the program and the actual frequency on the radio, sometimes it doesn't track at all. The frequency illustrated on the Rig Control screen (there is one for each radio) for VFO B and that on the Satellite Program screen for VFO B match but VFO A does not match and does not change the radio much if at all. BTW this is not when transmitting, if that is an issue.

It would seem to me that the changes would be instantaneous but this is not working at all. As a side note when selecting a particular satellite, the uplink mode (LSB) doesn't set properly either! Despite proper setup it always defaults to USB.

I had a ticket a while ago because the switch to manual doesn't seem to work for either radio, but the problem with the two VFOs and control of the radios is really bad and almost makes the program unusable for Doppler control.
Tags:
Steps To Reproduce:
Additional Information: https://tickets.hrdsoftwarellc.com/scp/tickets.php?id=10532
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2074 [2 - Next Dev List (Holding Area)] Bug crash always 2017-06-23 10:16 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: KB3NPH OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module:
Testing: Not Started
Summary: Sat Track crash when manual tuning
Description: Ticket #110120
Customer using IC-9100 with USB direct interface and Windows 10.

Juan posted 06/18/2017 2:39 AM
satellite tracking module locks up (not responding) after a minute or less when opened. I try switching between RX and TX frequencies to update my radio and the software becomes non responsive. I used same radio and computer before and I did not have this issue. I upgraded to latest version and issue still present. The only change in my environment is a Windows update performed automatically a few days ago.
Tags:
Steps To Reproduce: 6/23/2017 did a remote into customer's computer. When tracking is set to "Auto", (check marks in RX and TX) radio and software tracks normally. When the Auto tracking (RX and TX) is unchecked and the "Manual" is checked, the customer attempts to change the frequency via the radio dial, Satellite tracker becomes non-responsive and has to be killed via the task manager.

Tried adjusting the refresh rate in RC, but that had no effect. Determined a possible bug in the 9100 RC code. If the customer connects his FT-847 to the system and uses that radio, everything functions properly. Doppler tracking works fine and when he switches to "manual" tuning, the software follows the radio without crashing or locking the software. When it does lock, it appears to be ONLY the satellite tracker that locks up. RC and LB appear to operate normally after the SatTracker locks up.

Additional Information:
Attached Files:
Notes
(0007549)
WA9PIE   
2019-03-01 18:17   
I would like to see the customer re-test this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1965 [2 - Next Dev List (Holding Area)] Bug minor always 2016-11-16 14:21 2020-07-02 02:22
Reporter: NT9E Platform: PC  
Assigned To: K7ZCZ OS: Windoze  
Priority: normal OS Version: 10/64  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Label
Testing: Not Started
Summary: The radio pane connect button
Description: The radio pane connect button in the sat tracking module has the text connect when pushed or not. When pushed it should say disconnect not connect.
Tags:
Steps To Reproduce:
Additional Information: As you can see it is reading my radio because it is connected, so while connected it should say "Disconnect" so you can do just that, disconnect.
Attached Files: Connect.JPG (32,672 bytes) 2016-11-16 14:21
https://development.hamradiodeluxe.com/file_download.php?file_id=102&type=bug
jpg
Notes
(0007548)
WA9PIE   
2019-03-01 18:15   
This is pretty straight-forward. The Rotator app works the same way.

When the radio is NOT connected, the button should say, "Connect".
When the radio IS connected, the button should say, "Disconnect".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1927 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2016-08-14 22:44 2020-07-02 02:22
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Create popup for sysop announcement
Description: Users miss cluster announcements because they never leave the Spots view. In particular, users don't see communications about things that apply to their cluster node... like a reboot after a change (which is about a one-time per week event).

Initially, let's do this with announcements by WA9PIE that will be sent on the WA9PIE-2 cluster node. After we test it this way, I may be able to enable the sysop account and we'll do the same thing when the announcements are made by SYSOP.
Tags: ParityGap
Steps To Reproduce:
Additional Information: Requested:

when the following text can be parsed from the cluster:

"To LOCAL de WA9PIE: <message>"

Post the announcement in a popup box with an "Ok" button to dismiss the popup.

For example:

When parsing "To LOCAL de WA9PIE: WA9PIE-2 cluster will reboot at 0500Z tonight", then...

The popup box should say:

To LOCAL de WA9PIE:
WA9PIE-2 cluster will reboot at 0500Z tonight

There should be no options added to enable users to disable these things.
Attached Files: PopupAnouncement.jpg (48,429 bytes) 2016-08-14 22:44
https://development.hamradiodeluxe.com/file_download.php?file_id=85&type=bug
jpg
Notes
(0003005)
WA9PIE   
2016-08-14 22:56   
This is ONLY for when "To LOCAL de WA9PIE: " is parsed from the cluster.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1918 [2 - Next Dev List (Holding Area)] Enhancement minor always 2016-07-11 13:27 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Mode not changing when using BandMap
Description: Ticket #671153
In HRD Logbook --- When I run HRD, I put the DX Cluster at the bottom and the Bandmap 1 on the right side. When I click on a station on the Bandmap, my mode does NOT change (LSB/USB/CW) but it does when I do that on the DX Cluster at the bottom under the logbook.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0005426)
g3ucq   
2018-06-24 04:36   
Mode does not change from the Bandmap with my IC-7610 but does from the Cluster
(0005456)
WA9PIE   
2018-06-24 19:02   
Ok... moving this one back into the backlog.
(0007964)
K7ZCZ   
2019-05-30 16:54   
Switched to "enhnacement" per the team call on 2019-05-30

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1830 [2 - Next Dev List (Holding Area)] Bug major have not tried 2015-11-25 07:58 2020-07-02 02:22
Reporter: KB3NPH Platform:  
Assigned To: KB3NPH OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module:
Testing: Not Started
Summary: Yaesu Rotor CAT not working
Description: Ticket #404078
11/23/2015 5:38 pm Ari Paananen

Hello,
I have a Yeasu FT-2000 rig and a Yaesu G-1000DXC rotator. They are connected together with a mini-DIN6 cable. The rotator turns perfectly with both the control unit and the FT-2000 function keys so the connection between the rig and rotator control unit seem to be fine.

The rig is connected to my computer via microHAM micro Keyer II and normal CAT and digital operations with it work just fine. When I open the HRD Locator software, select "Yeasu Rotor CAT" and press "Connect" I seem to get a connection, but the software fails to show the current bearing correctly and it also doesn't seem to respond when I try to turn the rotator with it.

Sometimes when I leave it on for a longer time (several minutes) it suddenly responds and starts turning the motor but there is no logic in what it does. Usually in these cases the motor turns all the way to the maximum 360+90 degrees and then stops there. Also at this point looking at the Windows Task Manager, the rotator software is hogging as much of CPU as it can.

When I start the HRD Locator and connect, the Logfile tab shows this:

00:30:43 DDE Server DDE Initialized, ID = 01000080

00:30:43 General Loading layout from C:\Users\apa\AppData\Roaming\HRDLLC\HRD Rotator\WindowLayout001.xml

00:30:43 Zoom Mercator X = 0, Y = 0, ZoomLat = -1.$, ZoomLon = 100.0
00:30:43 Zoom Mercator X = 253, Y = 127, ZoomLat = 99.6, ZoomLon = 100.0
00:30:43 Zoom Mercator X = 444, Y = 222, ZoomLat = 100.0, ZoomLon = 100.0

00:30:43 DDE Server Registered service HRDRotator
00:30:43 DDE Server ---
00:30:43 DDE Server Callback:Type:000080A2
00:30:43 DDE Server Callback:Conv:00000000
00:30:43 DDE Server Callback:Data:00000000
00:30:43 DDE Server Callback:String1:HRDRotator
00:30:43 DDE Server Callback:String2:HRDRotator(0X00081580)
00:30:43 DDE Server Callback:Register

00:30:43 Zoom Mercator X = 444, Y = 222, ZoomLat = 100.0, ZoomLon = 100.0

00:30:48 Connect Rotator ......: Yaesu Rotor CAT
00:30:48 Connect Protocol .....: Yaesu Radio Ca Az
00:30:48 Connect Step size ....: Auto
00:30:48 Connect Min azimuth ..: -180
00:30:48 Connect Max azimuth ..: 540
00:30:48 Connect Elevation ....: No

00:30:48 Zoom Mercator X = 444, Y = 222, ZoomLat = 100.0, ZoomLon = 100.0
00:30:53 Zoom Mercator X = 253, Y = 127, ZoomLat = 99.6, ZoomLon = 100.0
00:31:00 Zoom Mercator X = 444, Y = 222, ZoomLat = 100.0, ZoomLon = 100.0
00:34:07 Zoom Mercator X = 253, Y = 127, ZoomLat = 99.6, ZoomLon = 100.0

At least the Min and Max azimuth readings are totally wrong, they should be from 0 to 450.
 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1804 [2 - Next Dev List (Holding Area)] Bug minor always 2015-10-17 11:04 2020-07-02 02:22
Reporter: py3og Platform: WINDOWS  
Assigned To: py3og OS:  
Priority: normal OS Version: 10  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module:
Testing:
Summary: Spot Calls on World Map
Description: Logbook/ALE

 "The Longitude and Latitude fields in the second page of the DM-780 ALE must be populated correctly in order for the call to be spotted on the World Map. When the call is found on the QRZ XML lookup, these fields are populated correctly. When the ALE is populated with the data from a previous logbook record, the Longitude and Latitude data is NOT being pulled into the DM-780 ALE field, therefore, it is NOT spotted on the World Map."
Tags:
Steps To Reproduce: Entering the callsign on ALE >>>>> no spots on World Map.
Additional Information: This bug was on Mantis by number 1815, but no more on there and not resolved.
Attached Files:
Notes
(0000655)
WA9PIE   
2015-10-18 22:28   
Is it possible that any of these are related to this item?

http://bugs.hrdsoftwarellc.com/view.php?id=1357
http://bugs.hrdsoftwarellc.com/view.php?id=1418
http://bugs.hrdsoftwarellc.com/view.php?id=1444
http://bugs.hrdsoftwarellc.com/view.php?id=1650
http://bugs.hrdsoftwarellc.com/view.php?id=1651
http://bugs.hrdsoftwarellc.com/view.php?id=1652

Could it be that the wrong mode is being reported to PSK Reporter and that's why the spots are not showing up (Mantis ID 1651)?
(0005799)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0005953)
g3ucq   
2018-08-09 03:59   
The DM780 ALE populates the World Map but the Logbook ALE does not.
Is that by design?
(0006786)
WA9PIE   
2018-12-21 14:53   
Maybe this is an enhancement request?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1790 [2 - Next Dev List (Holding Area)] Bug crash always 2015-10-12 13:36 2020-07-02 02:22
Reporter: k2ie Platform: i7  
Assigned To: OS: Windows 10  
Priority: high OS Version: Pro 64  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Cluster Email Alarm Configuration Crashes Logbook
Description: Configuring an email provider not listed on the dropdown causes the Logbook to hang.
Tags:
Steps To Reproduce: Open Logbook
Cluster Options
Alarms Email
Enter hostname of SMTP server
Enter port 465 for authenticated SSL login
Enter username/password
Enter outgoing from and to email addresses
Click send test
Wait minutes with no results
Close the Alarms Email window
MFC Application not responding dialog
Close the program
Additional Information: Note: Ticket for this issue originally opened on 3/14 but ticket cannot be located. This has been tried with Rackspace and with a local SMTP server as well. Same results. Works fine with gmail however.
Attached Files: Capture587.JPG (98,719 bytes) 2017-03-05 21:00
https://development.hamradiodeluxe.com/file_download.php?file_id=110&type=bug
jpg

Capture465.JPG (92,981 bytes) 2017-03-05 21:00
https://development.hamradiodeluxe.com/file_download.php?file_id=111&type=bug
jpg
Notes
(0003102)
WA9PIE   
2017-03-05 21:00   
Either way you play it... email alarms have been broken for a very long time.
(0005439)
k2ie   
2018-06-24 11:00   
Tried an authenticated port 465 connection to my local mailserver which is validated to work file with Outlook, Anrdroid, and Evolution.

Still broken, still causes logbook lockup requiring an end task on Logbook.
(0005801)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0006096)
k2ie   
2018-09-06 15:13   
Bug still exists and needs to be addressed.
(0007526)
k2ie   
2019-02-27 20:39   
Bug still exists and needs to be addressed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1730 [2 - Next Dev List (Holding Area)] Bug major always 2014-10-03 14:48 2020-07-02 02:22
Reporter: user36 Platform:  
Assigned To: PD9FER OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rotator
Sub-Module: Rotators
Testing: Not Started
Summary: Rotator - Yaesu Rotators via CAT command do not function properly
Description: Yaesu rotators connected to rig and controlled by cat command are off by 180 degrees. North/South stop does not fix this problem.

Clue is that the range of the rotator is 450 degrees of rotation, +/- 255 from center (either 0/360 for north CENTER, or 180 for south CENTER). ***See Logfile dump in notes for more info.***
Tags:
Steps To Reproduce: - Connect Rig Control to Yaesu rig with Yaesu rotator connected to it.
- Launch Rotator
- Connect to Yaesu Rotator via CAT
- Observe headings on Rotator do not match actual headings of Yaesu rotator.
Additional Information: 13:38:08 DDE Server DDE Initialized, ID = 01000080
                      
13:38:08 General Loading layout from C:\ProgramData\HRDLLC\HRD Rotator\WindowLayout001.xml
                      
13:38:09 Connect Rotator ......: Yaesu Rotor CAT
13:38:09 Connect Protocol .....: Yaesu Radio Ca Az
13:38:09 Connect Step size ....: Auto
13:38:09 Connect Min azimuth ..: -180
13:38:09 Connect Max azimuth ..: 540
13:38:09 Connect Elevation ....: No
Attached Files: RotatorStopRange.png (82,400 bytes) 2019-03-01 17:27
https://development.hamradiodeluxe.com/file_download.php?file_id=695&type=bug
png
Notes
(0007538)
PD9FER   
2019-03-01 06:45   
Related:
Ticket #291705
(0007546)
WA9PIE   
2019-03-01 17:27   
The range of travel and offset are configurable settings in the Rotator app as shown in the attached.

I just referred another customer to these settings for the same purpose and it resolved their problem. I'm going to refer this customer as well.
(0007547)
WA9PIE   
2019-03-01 17:44   
I've contacted this customer and I'm waiting for him to set a 180 degree offset and confirm that this solved his problem.
(0007697)
PD9FER   
2019-03-18 04:14   
New Ticket report #859863
Asked the Customer the same as Mike did above.
Resulting in only be able to set Serial Com Ports (for external controllers)
There is no option to assign it to Yaesu CAT
(0008105)
WA9PIE   
2019-06-16 17:18   
Ferry - can you explain this further?
(0008115)
PD9FER   
2019-06-16 23:35   
Standard Rotor controllers can be selected Via a Comport and then be given a offset.
However certain Yaesu radio's have their own Rotor Port, this is controlled by CAT.
In this case, Yaeasu CAT is NOT selectable (only com ports), meaning No offset can be given.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1334 [2 - Next Dev List (Holding Area)] Bug major always 2013-12-23 21:44 2020-07-02 02:22
Reporter: Support Platform: None  
Assigned To: OS: Empty  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: Satellite TX mode not properly transferred to FLEX 1500 from HRD
Description: HRD 5.24.0.36 with Satellite Tracking module attached to FlexRadio FLEX-1500
running PowerSDR 2.3.5. Satellite set to FO-29. Transverters 145-28 MHz attached
to transmit side and 435-28 attached to receive side. Both RX VFO-A and TX VFO-B
checked and correctly update VFO A and VFO B on the FLEX-1500. VFO B set to TX
on 1500. In the radio panel of the HRD Satellite Tracking module, RX-Mode is set
to USB and TX-Mode is set to LSB.

However, when the system transmits (either via PTT on the 1500, TX is clicked on
HRD, or TX is clicked in the Satellite radio panel) the mode of the FLEX is not
changed to LSB but instead transmits USB.
Tags:
Steps To Reproduce:
Additional Information: Reported by n4kit

Reported from Support by W5RKN, w5rkn@w5rkn.com
Attached Files:
Notes
(0008078)
K7ZCZ   
2019-06-15 12:19   
I don't have any model of Flex radio, so I'm not able to work on this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1328 [2 - Next Dev List (Holding Area)] Bug major always 2013-12-23 21:44 2020-07-02 02:22
Reporter: Support Platform: Dell Precision 670  
Assigned To: OS: Windows XP  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: TS-2000 - inverting transponder TX Freq off [5.23.0.12]
Description: Satellite Tracker 5.23.0.12

When using RX manual tuning with an inverting transponder satellite the TX
frequency is a few kHzs off of where it should be. Radio is a Kenwood TS-2000.

Three examples follow:

FO-29 RX=435.850.00 TX=145.954.60 [should be 145.950.00]

AO-07 RX=145.950.00 TX=432.151.27 [should be 432.150.00]

VO-52 RX=145.900.00 TX=435.245.23 [should be 435.250.00]
Tags: Kenwood, TS-2000, TS2000
Steps To Reproduce: Select satellite, click on Tuning Dial, select transponder, check []RX, check
[]TX, check []manual tuning. Manually tune radio to RX = 435.850.00 TX freq
should tune to 145.950.00 but is off.
Additional Information: Reported by k7dcl

Satellite transponder freqs are set to the middle of the pass band.

FO-29 RX=435.850.00 TX=145.950.00

AO-07 RX=145.950.00 TX=432.150.00

VO-52 RX=145.900.00 TX=435.250.00
Attached Files:
Notes
(0007515)
WA9PIE   
2019-02-26 18:00   
I'm changing this from Rig Control to Satellite Tracking.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1393 [2 - Next Dev List (Holding Area)] Bug major N/A 2013-12-23 21:44 2020-07-02 02:22
Reporter: Support Platform: None  
Assigned To: OS: Empty  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: Sat tracker will not control 2 FT857's
Description: When connecting to 2 FT857's via separate cat controls (38400 baud), the sat
tracker will only update the RX radio. TO get the TX radio to control, the RX
radio control check box must be deselected
Tags:
Steps To Reproduce: Track any satellite with both radios enabled. Only RX radio will update the
frequency. Uncheck RX radio to get the Tx Radio to update frequency.
Additional Information: Reported by wm9q
Attached Files:
Notes
(0008076)
K7ZCZ   
2019-06-15 12:17   
I don't have this radio (not to mention two of them) so I'm not able to work on this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3583 [2 - Next Dev List (Holding Area)] Maintenance minor always 2019-11-13 02:32 2020-07-02 02:20
Reporter: PD9FER Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: (W)orked indicators are gone
Description: As discussed in the meetings earlier (I can't find the Mantis# for it), the W icon has gone for Callsign, IOTA, Country and Locator
Tags:
Steps To Reproduce: Open ALE
Lookup an call in a Country, IOTA or Locator you worked before
(See screenshot)
Additional Information: Ticket #643901
Attached Files: Capture.JPG (32,843 bytes) 2019-11-13 02:32
https://development.hamradiodeluxe.com/file_download.php?file_id=841&type=bug
jpg

wkrd.JPG (118,118 bytes) 2019-11-13 07:24
https://development.hamradiodeluxe.com/file_download.php?file_id=844&type=bug
jpg
Notes
(0009320)
K7ZCZ   
2019-11-14 18:31   
In the team call on 2019-08-29, it was agreed that these indicators would be removed until a good design could be put together for how they'd work.
(0009321)
WA9PIE   
2019-11-14 20:09   
I think that when we've recorded a customer's "bug report" that we should refrain from moving it to "Resovled" and "Won't fix"... when it's a case where we're saying that we do intend to address this when a "good design can be put together for how this will work."

To that end... I've reopened it, marked it confirmed, and assigned it to me we come up with this good design.
(0009322)
K7ZCZ   
2019-11-14 20:21   
I resolved this won't fix because the team had deliberately decided to remove the feature from the product, per the related issues.

If the team has deliberately decided to reverse that decision and undo the work done to carry it out, then it should do so with clarity and clear intention.

At best, this issue is a duplicate and should remain resolved since you document your intention to come up with a design in 2801.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3582 [2 - Next Dev List (Holding Area)] Bug minor always 2019-11-13 02:20 2020-07-02 02:20
Reporter: PD9FER Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: No eQSL and LoTW indication in ALE
Description: Some versions ago the ALE showed if the contact uses eQSL and/or LoTW
These indicators no longer work (They do work in the Lookup pane VIEW > LOOKUP)
Tags:
Steps To Reproduce: Open ALE
Do a Call lookup on a station known having eQSL and/or LoTW
Watch the indicaters (see attached picture)
Additional Information: Ticket #623620
Attached Files: Capture.JPG (49,565 bytes) 2019-11-13 02:20
https://development.hamradiodeluxe.com/file_download.php?file_id=840&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3557 [2 - Next Dev List (Holding Area)] Bug minor always 2019-11-06 16:25 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add DXCC Country as the last row in the address field for HamCall.net
Description: Because the address field is used for the mailing label, and because our customers are International, we should add the DXCC country as the last row in the address field.

(The address field is correctly being placed here for all other lookup methods except Hamcall; separate Mantis issue for it.)
Tags:
Steps To Reproduce: 1 - Launch Rig Control
2 - Launch Logbook
3 - Go to Tools > Configure > Callsign Lookup... Enable tab
4 - Add only HamCall.net
resulting order is UCSDB (Public), UCSDB (Private), HamCall.net, Country List
5 - Press "Apply"
6 - Click the "Test" tab
7 - Enter "WA9PIE" (without quotes) and click "Lookup"
8 - Observe the results where the address field does not populate Country at the bottom of the address field.

See attached image.
Additional Information: I don't consider this a show-stopper for the 6.7 release. If it gets done... great. Otherwise, we can do this in an upcoming maintenance release.
Attached Files: Hamcall address field.png (88,000 bytes) 2019-11-06 16:25
https://development.hamradiodeluxe.com/file_download.php?file_id=819&type=bug
png

CallsignLookupMapping4x.xlsx (25,936 bytes) 2019-11-06 22:22
https://development.hamradiodeluxe.com/file_download.php?file_id=820&type=bug
Notes
(0009185)
K7ZCZ   
2019-11-06 21:55   
The code is behaving per the specification right now. The specification says that the country line (the last line) of the address comes from field #209, which the API documentation describes as "mailing country". The lookup from WA9PIE yields no value for 209, so nothing is aded to the field.

The DXCC country field (the undocumented #225 field) is also blank, so there's no way to compute a DXCC country.

I don't see a way to do what you're asking. That must mean that you've actually intended to ask for something else. What is it? For example, the WA9PIE lookup returns "USA" for field #189, which the API describes as "Prefix Country". Should that value be used instead of the mailing country?

(0009186)
WA9PIE   
2019-11-06 22:22   
I had it wrong in the version of the field mapping spec you're looking at.

It later occurred to me that - if we're obtaining the country from the Country List... then it's a matter of putting the country name from the Country List as the last line in the address field.

Sorry about that. I'm attaching an in-progress version of that field mapping spec that I'm using to keep track of the "as-built" mapping. You'll see this in the yellow high-lighted HamCall.net column.
(0009193)
K7ZCZ   
2019-11-07 08:27   


I don't think releasing a product with a specification that' described as "in-progress" is good process.

If the code is changed to match what you're asking for here, the repro case provided still won't show a country name in the address because the call sign given doesn't offer a DXCC number at this data source. Is that what's desired?

(0009195)
WA9PIE   
2019-11-07 08:30   
Put the country from the distilled results on the last row of the address field.
(0009197)
K7ZCZ   
2019-11-07 10:09   
Right now, code for each lookup source produces a set of name-value pairs. In this case, the HamCall lookup produces an "Address" name with the a value that has an address that doesn't include a country name. The country name isn't included because this source doesn't provide one. This arrangement matches the specification, where each column in the spreadsheet shows a set of mappings from source fields to logbook column fields.

Since the HamCall lookup source (like all other lookup sources) atomically produces each named value it contributes to the results, we can't readily take one named value from the distilled results and use that value to edit the existing results from another value, from another source.

The lookup code works this way so that each source standardizes its representation of the results in a way that can be readily combined, displayed to the user, and placed in a logbook database record. For that standardization, "ADDRESS" is the name of one of the values. While other values exist which might be part of the address, the "ADDRESS" value is computed by each lookup source for itself, using its locally-known fields and rules.

Changing that would require removing the "ADDRESS" field and breaking it into component parts, standardized across each component, so that something added to the distillation step could consider different values from different sources when displaying the final "ADDRESS" value to users, or preparing COL_ADDRESS for the database.

Until today, this approach was compatible with the specification. The approach is modular, isolated, readily exensible, easy to understand, and pretty flexible.

Now that it's not, we're forced to consider alternatives -- and to do so just before a shipping deadline.

My first suggestion for an alternative would be to consider different sources for the country name. First, use field #209 ("Mailing address country"), if it's available. If not, use field #189 ("Prefix Call") from this source, if it is avaialble. If not, use the DXCC country name based on looking up the DXCC entity number in field #225.

Or, maybe there should be a different order.

As this repro case shows, there are records from this data source which have neitehr #209 nor #225 populated. Since the specification says to ignore #189, the source ends up producing no country name in the address (or in the COL_COUNTRY field, or any of the related fields).

If you'd like, we could have this component side-step the Coutry List component and have the country list produce a country name based on the prefix matching logic it has. If we take this approach, should it be done unconditionally without considering any other fields? Or should it be done only if certain fields are blank? In which order?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3556 [2 - Next Dev List (Holding Area)] Bug minor always 2019-11-06 16:23 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Add DXCC Country as the last row in the address field for callook.info
Description: Because the address field is used for the mailing label, and because our customers are International, we should add the DXCC country as the last row in the address field.

(The address field is correctly being placed here for all other lookup methods except Hamcall; separate Mantis issue for it.)
Tags:
Steps To Reproduce: 1 - Launch Rig Control
2 - Launch Logbook
3 - Go to Tools > Configure > Callsign Lookup... Enable tab
4 - Add only Callook.info
resulting order is UCSDB (Public), UCSDB (Private), Callook.info, Country List
5 - Press "Apply"
6 - Click the "Test" tab
7 - Enter "WA9PIE" (without quotes) and click "Lookup"
8 - Observe the results where the address field does not populate Country at the bottom of the address field.

See attached image.
Additional Information: I don't consider this a show-stopper for the 6.7 release. If it gets done... great. Otherwise, we can do this in an upcoming maintenance release.
Attached Files: Callook info address field.png (63,997 bytes) 2019-11-06 16:23
https://development.hamradiodeluxe.com/file_download.php?file_id=818&type=bug
png
Notes
(0009187)
K7ZCZ   
2019-11-06 22:22   
I think it's too late to do this work for the imminent release as it would be too destabilizing. If you're insistent on getting it done, then you should have one of the other developers look into it. You probably should do that anyhow, so they can start getting up to speed and are able to make progress in my absence.

(0009188)
WA9PIE   
2019-11-06 22:24   
I could do that. But for this change, I suspect it would take far longer to get someone up-to-speed vs. the amount of time it would take to make this change. Dunno.

But, the point regarding this change being made so close to the release is a concern that I share.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3526 [2 - Next Dev List (Holding Area)] Bug major always 2019-10-29 08:53 2020-07-02 02:20
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Adding a call sign previously worked error in ALE
Description: Adding a callsign that has previously been worked, pressing Partial or Exact does not populate the Logbook tab in ALE.
Only under certain circumstances.
Tags:
Steps To Reproduce: Open the Logbook and enter a call sign that has previously been worked.
Press the Logbook tab and either the Partial or Exact should be pressed.
Press the Lookup button.
Data is added to the ALE pane but no data shows under the Logbook tab.
Press the 'Find' button.
Previous QSOs will then show under the Logbook tab.
Press the Reset (F4) button to remove all the data.
Now re enter the same call sign as before and press Lookup.
Now press either the Partial or Exact buttons. The Logbook will be populated.
Now press Cancel to close the ALE.
Reopen the ALE and add the same call sign as before.
Press the Lookup button and the ALE pane is populated.
Press either the Partial or Exact buttons again and the Logbook is not populated.


Additional Information: This shows that the Logbook lookup ONLY works after the Find button is used but not after the Lookup button is used.
Is that the way it should be? I think not.
System Description
Attached Files:
Notes
(0009113)
w4elp   
2019-11-02 06:59   
Confirm G3UCQ's findings. Populating the Logbook tab with previous QSOs was automatic prior to v6.7, or perhaps the FIND button was persistent once clicked.. Having to click FIND each time a call is entered is very annoying.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3512 [2 - Next Dev List (Holding Area)] General major always 2019-10-23 00:34 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Redesign of the Callsign Lookup's Enable tab UI
Description: In the 6.7.0.235 beta build, the Callsign Lookup dialog box contains a list of things that are meant to be re-ordered with things that are not meant to be re-ordered (meanwhile, I was able to move things that were not meant to be moved). I think this will confuse customers.

The purpose of this change request is to suggest a change in the UI that is intended to provide better clarity for the users about how the dialog box and feature works.
Tags:
Steps To Reproduce: - Launch Logbook
- Go to Tools, Configure, Callsign Lookup... Enable tab
- Observe how this could be confusing (those things that aren't meant to be reordered are among things that are meant to be reordered)
Additional Information:
Attached Files: CallsignLookupEnabledMethods.png (51,012 bytes) 2019-10-23 00:34
https://development.hamradiodeluxe.com/file_download.php?file_id=793&type=bug
png
Notes
(0009037)
K7ZCZ   
2019-10-28 12:19   
I don't think we have any evidence that this is confusing to our customers; we also haven't yet had a build where the implementation has been completely bug-free. It is thus hasty to discard hours of work until we have some concrete feedback from customers who've had a chance to use the completed implementation. If we find evidence that there are misunderstandings caused by the UI, I think we can come up with changes or enhancements to the existing design based on that feedback before we entertain a redesign.

With this reasoning, I'm resolving this as won't fix.
(0009206)
WA9PIE   
2019-11-08 02:22   
Reopened for further/future conversation.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3511 [2 - Next Dev List (Holding Area)] General major always 2019-10-22 20:05 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Callsign Lookup dialog box has confusing UI
Description: In the 6.7.0.235 beta build, the Callsign Lookup dialog box contains a list of things that are meant to be re-ordered with things that are not meant to be re-ordered (meanwhile, I was able to move things that were not meant to be moved). I think this will confuse customers.

The purpose of this change request is to suggest a change in the UI that is intended to provide better clarity for the users about how the dialog box and feature works.

We also need to add Up/Down buttons to the right of the "Enabled Methods" so that the user will know that they can re-order them.
Tags:
Steps To Reproduce: - Launch Logbook
- Go to Tools, Configure, Callsign Lookup... Enable tab
- Observe how this could be confusing
Additional Information:
Attached Files: CallsignLookupEnabledMethods.png (51,012 bytes) 2019-10-22 20:05
https://development.hamradiodeluxe.com/file_download.php?file_id=792&type=bug
png
Notes
(0008906)
K7ZCZ   
2019-10-22 23:59   
There are really three issues here: The missing up-down buttons, the ability to move items that shouldn't be moved, and the design of the UI itself.

Please open separate issues for each. Granular Mantis issues are easier to track, facilitate clear communication, testing, and documentation.
(0008907)
WA9PIE   
2019-10-23 00:47   
I have created three Mantis issues to separate out this work. I've placed them as child issues to this one.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3472 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-09-27 03:59 2020-07-02 02:20
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: normal OS Version: 10 64 bit Home  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: settings for brightness and contrast in waterfall
Description: Please add controls to adjust Brightness and Contrast for the waterfall.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: N1MM.jpg (78,825 bytes) 2019-11-06 04:13
https://development.hamradiodeluxe.com/file_download.php?file_id=816&type=bug
jpg
Notes
(0008711)
K7ZCZ   
2019-09-27 09:08   
For now, the value reported from the radio is mapped to a range of 0..255. The color is chosen by using the mapped value for the red and green components of the color. The blue component is chosen by taking three times the mapped value, capped at 255. Thus, no signal strength maps to black, and full signal strength maps to white. Intermediate signals map to other colors with a stronger blue component; 50% signal strength is shown with #8080FF, for example.

Mathematically, the color is chosen by:

scale = 255 * (sample / fullScale)
color = RGB(scale, scale, max(255, scale * 3))


where sample is the given sample value in the radio's scale and fullScale is the radio's documented full-scale value.

The existing function, then, already has 100% dynamic range as it uses the full range of colors for the full intensity of the radio's scale; an since that range is drawn on a black background, it already has maximum contrast.

There are any number of different ways to convert signal strength into a visual representation, including color and intensity. I don't know of any standardized algorithms or transforms. Since this is largely a matter of preference, I think we should explore different mappings and keep those that seem particularly popular or effective. It will take time to collect feedback and suggestions and test.

Until then, the easiest way to adjust the display is with the base-line reference setting either in the panadapter window or on the radio.
(0008811)
K7ZCZ   
2019-10-13 14:29   
With the color settings available, I'm resolving this fixed. If you have some specific idea of how you'd like to mathematically define "contrast" and "brightness" as quantities in the context I've supplied, please do let me know and we can consider it.
(0008973)
WA9PIE   
2019-10-23 08:12   
Any word on the disposition of this item?

Code needed? Or not?
(0008974)
g3ucq   
2019-10-23 08:14   
Which ever way is implemented, the waterfall is too dark with poor contrast.
(0009156)
g3ucq   
2019-11-06 04:13   
N1MM+ has a contrast control so I can match the waterfall to that on my IC-7610.
(0009183)
WA9PIE   
2019-11-06 16:31   
I'm taking this out of Resolved status. It's clearly not "resolved."

It may be something we take-on after the initial 6.7 release.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3458 [2 - Next Dev List (Holding Area)] Enhancement feature have not tried 2019-09-25 10:28 2020-07-02 02:20
Reporter: g3ucq Platform: PC  
Assigned To: g3ucq OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Panadapter
Testing: Not Started
Summary: add ability to resize the panadapter window
Description: Ability to resize the panadapter window
Tags:
Steps To Reproduce: Open Rig Control/Tools/Panadapter(Main)
It is not possible to resize the window.
It should be possible to resize the window at least horizontally.
Additional Information: The Panadapter needs to be added to the Module (Rig Control/Panadapter)
System Description
Attached Files:
Notes
(0008675)
K7ZCZ   
2019-09-25 17:21   
It is already possible to resize the panadapter window vertically. We'll eventually add the scaling necessary to resize the window horizontally.
(0008690)
g3ucq   
2019-09-26 08:35   
The window can be resized from the top up but not from the bottom down.
(0008696)
K7ZCZ   
2019-09-26 09:12   
Vertical resizing works both from the top edge or the bottom edge for me, no problem.
(0009077)
WA9PIE   
2019-10-29 06:55   
John,

Can you restest this, based on MikeB's comments?
(0009078)
g3ucq   
2019-10-29 08:29   
Yes, the window can be resized from top and bottom but not horizontally even though the resize arrows show.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3437 [2 - Next Dev List (Holding Area)] Bug crash always 2019-08-24 12:56 2020-07-02 02:20
Reporter: KB3NPH Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Functional
Testing: Not Started
Summary: Immediate crash and minidump when you start HRD
Description: Ticket #516291 - Customer installed HRD and when he tries to run it immediately crashes indicating a minidump was created. There's no splash screen, no nothing except the error screen indicating that it created a minidump.

I pulled the minidump and it's attached.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: HamRadioDeluxe_20190824_173317.mdmp (472,598 bytes) 2019-08-24 12:56
https://development.hamradiodeluxe.com/file_download.php?file_id=734&type=bug
Notes
(0008435)
PD9FER   
2019-08-25 02:42   
Set this to Private Please!
(0008449)
K7ZCZ   
2019-08-26 15:08   
This dump is from build 6.6.0.237.

Looks like something is failing in the new licensing code. The callstacks are here. The HRESULT from the QLM call looks like E_POINTER, but I'm not positive that the args match the sources I have completely. I don't see ProductID on the stack, for example.

Doug should take a look.

0:000> .ecxr
eax=0039c7dc ebx=0039c880 ecx=00000003 edx=00000000 esi=728d520c edi=72911e8c
eip=74bbc5af esp=0039c7dc ebp=0039c82c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
KERNELBASE!RaiseException+0x58:
74bbc5af c9              leave
0:000> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 0039c82c 7286b8da e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
01 0039c870 728690a4 0039c880 72911e8c 728d3314 HRDStation!_CxxThrowException+0x66 [d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 129] 
02 0039c890 72868c91 80004003 008c7a5c 046e0034 HRDStation!_com_raise_error+0x24 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comraise.cpp @ 18] 
03 0039c8ac 726fdb45 80004003 046e0034 728e2660 HRDStation!_com_issue_errorex+0x91 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comsupp.cpp @ 66] 
04 0039c8e0 726ffd8f 046e0034 00000000 00000006 HRDStation!QlmLicenseLib::IQlmLicense::DefineProduct+0x85 [c:\hrd66\hrdstation\release\qlmlicenselib.tli @ 2675] 
05 0039c95c 726f1a90 6c2c3142 ffffffff 00027060 HRDStation!LicenseValidator::LicenseValidator+0x22f [c:\hrd66\hrdstation\licensevalidator.cpp @ 134] 
06 0039d6a8 726f5f74 00000000 6c2c309a 013b1590 HRDStation!HRDSoracoLicenser::CheckLicense+0xe0 [c:\hrd66\hrdstation\hrdsoracolicenser.cpp @ 61] 
07 0039d770 726f30e8 00c3d7af 6c0db96b 013b1590 HRDStation!_HRDInitStation+0x2a4 [c:\hrd66\hrdstation\hrdstationlicense.cpp @ 320] 
08 (Inline) -------- -------- -------- -------- HRDStation!CHRDStationApp::InitializeStation+0xc7 [c:\hrd66\hrdstation\hrdstation.cpp @ 160] 
09 0039d774 00c3d7af 6c0db96b 013b1590 00c3d620 HRDStation!InitializeStation+0xc8 [c:\hrd66\hrdstation\hrdstation.cpp @ 129] 
0a 0039fd4c 0115725f 00000000 014c885c 7efde000 HamRadioDeluxe!CHamRadioDeluxeApp::InitInstance+0x18f [c:\hrd66\hamradiodeluxe\hamradiodeluxe.cpp @ 260] 
0b 0039fd64 00e9f443 00b80000 00000000 007e1a7e HamRadioDeluxe!AfxWinMain+0x5f [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37] 
0c (Inline) -------- -------- -------- -------- HamRadioDeluxe!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
0d 0039fdb0 766b343d 7efde000 0039fdfc 772a9802 HamRadioDeluxe!__scrt_common_main_seh+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0e 0039fdbc 772a9802 7efde000 7702d5e3 00000000 kernel32!BaseThreadInitThunk+0xe
0f 0039fdfc 772a97d5 00e9f4c7 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
10 0039fe14 00000000 00e9f4c7 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 0039c82c 7286b8da KERNELBASE!RaiseException+0x58
01 0039c870 728690a4 HRDStation!_CxxThrowException(void * pExceptionObject = 0x0039c880, struct _s__ThrowInfo * pThrowInfo = 0x72911e8c)+0x66 [d:\agent\_work\3\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 129] 
02 0039c890 72868c91 HRDStation!_com_raise_error(HRESULT hr = <Value unavailable error>, struct IErrorInfo * perrinfo = <Value unavailable error>)+0x24 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comraise.cpp @ 18] 
03 0039c8ac 726fdb45 HRDStation!_com_issue_errorex(HRESULT hr = 0x80004003, struct IUnknown * punk = 0x046e0034, struct _GUID * riid = 0x728e2660 {41791E5A-1B22-40F0-A7B2-322F361DFFBC})+0x91 [d:\agent\_work\3\s\src\vctools\compiler\cxxfe\sl\vccom\comsupp.cpp @ 66] 
04 0039c8e0 726ffd8f HRDStation!QlmLicenseLib::IQlmLicense::DefineProduct(class _bstr_t productName = class _bstr_t, long majorVersion = 0n6, long minorVersion = 0n6, class _bstr_t encryptionKey = class _bstr_t, class _bstr_t persistenceKey = class _bstr_t)+0x85 [c:\hrd66\hrdstation\release\qlmlicenselib.tli @ 2675] 
05 0039c95c 726f1a90 HRDStation!LicenseValidator::LicenseValidator(void)+0x22f [c:\hrd66\hrdstation\licensevalidator.cpp @ 134] 
06 0039d6a8 726f5f74 HRDStation!HRDSoracoLicenser::CheckLicense(int bForceDlg = 0n0)+0xe0 [c:\hrd66\hrdstation\hrdsoracolicenser.cpp @ 61] 
07 0039d770 726f30e8 HRDStation!_HRDInitStation(void)+0x2a4 [c:\hrd66\hrdstation\hrdstationlicense.cpp @ 320] 
08 (Inline) -------- HRDStation!CHRDStationApp::InitializeStation+0xc7 [c:\hrd66\hrdstation\hrdstation.cpp @ 160] 
09 0039d774 00c3d7af HRDStation!InitializeStation(void)+0xc8 [c:\hrd66\hrdstation\hrdstation.cpp @ 129] 
0a 0039fd4c 0115725f HamRadioDeluxe!CHamRadioDeluxeApp::InitInstance(void)+0x18f [c:\hrd66\hamradiodeluxe\hamradiodeluxe.cpp @ 260] 
0b 0039fd64 00e9f443 HamRadioDeluxe!AfxWinMain(struct HINSTANCE__ * hInstance = 0x00b80000, struct HINSTANCE__ * hPrevInstance = 0x00000000, wchar_t * lpCmdLine = 0x007e1a7e "", int nCmdShow = 0n1)+0x5f [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37] 
0c (Inline) -------- HamRadioDeluxe!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
0d 0039fdb0 766b343d HamRadioDeluxe!__scrt_common_main_seh(void)+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0e 0039fdbc 772a9802 kernel32!BaseThreadInitThunk+0xe
0f 0039fdfc 772a97d5 ntdll!__RtlUserThreadStart+0x70
10 0039fe14 00000000 ntdll!_RtlUserThreadStart+0x1b

(0008450)
DOUG   
2019-08-26 21:52   
ProductID is hard coded to 3.

First off, we can "fix" the crash, meaning that it won't crash happen any more. But this is a symptom that QLM in general is not working. All these QLM calls throw com exceptions when they fail, but for the most part we have not been catching them (as Mike B. has noticed before). There really aren't supposed to fail even the QLM sample code doesn't catch these either. This call "DefineProduct" pretty much does nothing to crazy, this is hidden in the dll but with process monitor I can tell it is not accessing any file or registry when I step over it.

So the fix would be to just catch it and return some generic error message. The similar exceptions I have caught from QLM before is just "Unknown Error".

So while I have no magic cure for this one, here is what I can tell from the dump.
The crash on the first call after loading the dll. So this probably means that there is some general compatibility issue here.
If I had to guess this would be an issue with a dll the QLM is dependent on (I believe is uses a bunch of .net assemblies). There is also a slight possibility that they have an old version of the dll installed and registered on that machine.

One thing that jumps out at me is that this appears to be a Windows 7 machine, While this shouldn't be a problem, it probably increases the likelihood that some required dll is not there. I would ask user the make sure all updates are applied and the latest .net framework updates are installed.

What is the normal protocol for trying to support users with a crash like this?
(0008451)
PD9FER   
2019-08-27 06:03   
The procedure I use resolves the issue at 99% of the time.
Just by letting the customer do a full Windows Update, reboot and Install Ham Radio Deluxe again on top of the existing install.
(0008452)
K7ZCZ   
2019-08-27 09:53   
In the source code, I can see the magic number "3" hard coded as the first parameter to IQlmLicense::DefineProduct().

However, it's absent from both the kp and kb call stacks. This seems really strange, as digging through the disassembly I don't see how the parameter value 3 is developed or passed to the DefineProduct() method. It's as if the parameter doesn't exist. Given the HRESULT is E_POINTER, I'm trying to figure out why the first parameter in the kb dump shows 0x00000000 (before 0x00000006) in the DefineProduct() call.

Indeed, it's a Windows 7 host. The dump shows version 4.0.30319 of mscoreei.dll and the mscorelib.ni modules. Is that too old?
(0008566)
KB3NPH   
2019-09-19 07:56   
(Last edited: 2019-09-19 08:00)
This issue has been resolved. It turns out to be that MS .NET Framework 4.5 or newer has to be installed on the computer due to the QLM additions to the HRD software. So, we can mark this Mantis issue resolved with no action required, although as an afterthought, it might be a good idea to put a check in the installer and if .NET 4.5 or newer is not found on the computer, it should be downloaded and installed in our installer.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3431 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-08-13 10:24 2020-07-02 02:20
Reporter: KB3NPH Platform:  
Assigned To: JOSE OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.6.0.237  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 6.7.0.226  
    Target Version:  
Module: Rotator
Sub-Module: Rotators
Testing: Not Started
Summary: Fox Delta Rotator Controller Support
Description: Customer in Ticket #168924 has a Yaesu G-5500 rotor and a Fox Delta controller which emulates the Yaesu GS-232B controller. The Yaesu products support 450 degree rotation meaning when using OEM Yaesu rotor and controller, the rotor is capable of rotating past the normal 360 degree limits.

According to the Fox Delta manual, the controller is supposed to allow the 450 degree rotation when using the GS-232B emulation. Unfortunately the customer can only get 360 degree rotation and can not get the additional 90 degree over run.

Do we have a bug in our GS-232B code or is this a limitation with the emulated GS-232B firmware in the Fox Delta controller?

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008403)
JOSE   
2019-08-14 00:19   
Change range from 0-360 to 0-450 in the code. It will need to be tested for correct behavior
(0008471)
KB3NPH   
2019-08-30 09:56   
The fix for this issue did NOT work. Sent the beta release to the customer for testing and he reported the rotor still will only travel 360 degrees. It will Not move to the 450 degree position.
(0008472)
JOSE   
2019-08-30 10:23   
Can you find out how the customer is trying to move to 450. From the Rotor gauge only 0 to 360 is allowed.
(0008505)
KB3NPH   
2019-09-03 11:31   
Jose, are you talking the gauge on the rotator GUI will only go from 0 to 360 and will not indicate any over-run? The customer is using this for satellite tracking. There are times, for example, when the satellite is passing, west to east and is low on the northern horizon. The 450 degree over run, allows you to pick up the satellite, say at 270 degrees. The satellite is tracking west to east, but low on the northern horizon. Normally if the rotator is set with a north stop, the satellite would be tracked from 280 to 359 degrees, then to continue tracking the beam would have to swing back the other way to the 001 degree to pick up the satellite past north (360 degree) and on to it's LOS at say 090 degrees. Being able to have continuous tracking from 270 to 360, then over run the stop so it can track to the 450 degrees. I hope you understand what I am trying to explain.
(0008506)
JOSE   
2019-09-03 11:41   
Yes as far as I know the gauge on the rotator only shows 0 to 360 and doesn't indicate any over-run. But the limits have been extended so the rotator code would accept upto 450 degrees. Depending on the rotator I see different limits. But I don't know how the satellite tracking handles it. In the LogFile you should be able to see what is the actual location of the rotator.
(0009018)
KB3NPH   
2019-10-25 12:09   
Jose, I can understand the gauge only indicating 0 to 360 and that it will not indicate the over-run, but do you have any possible idea why his "Fox Delta" controller that emulates the GS-232B az/el rotor controller will not allow the overrun to 450 degrees when the PST ROTATOR software works perfectly with his Fox Delta emulating the GS-232B as/el controller. I really need to be able to give Randy an answer about this.
(0009019)
JOSE   
2019-10-25 12:21   
I don’t understand what you expect to see. Like I said the controller has now 0-450 limits so any limitations don’t come from from the rotator software so I am at a loss as to what you are looking for.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3430 [2 - Next Dev List (Holding Area)] Bug major always 2019-08-12 14:23 2020-07-02 02:20
Reporter: g3ucq Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 10 64 bit Home  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Import Export
Testing: Not Started
Summary: HRD ADIF Import no longer Importing any HRD User_Defined_Fields.
Description: As the title reported by G4NVB
Tags:
Steps To Reproduce: 1: Export a Logbook which contains information in any of the HRD User_Defined_Fields (ensuring ADIF + Ham Radio Deluxe Radio Button is selected).

2: Inspect the Exported ADIF File to confirm that the HRD User_Defined_Fields are populated.

3: Create an empty HRD LOgbook.

4: Import the saved ADIF File.

5: Observe that the HRD User_Defined_Fields are no longer populated.
Additional Information: I confirm G4NVB's findings.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3423 [2 - Next Dev List (Holding Area)] Maintenance minor always 2019-08-10 22:49 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Server
Testing: Not Started
Summary: Differentiate between auto-renewals and non-auto-renewals in QLM
Description: Each day, there are three scheduled tasks in QLM Management Console that sends a renewal reminder email to customers who have a Maintenance Plan Date that is 30, 15, and 3 days from "today", respectively. [Based on queries defined in QLM for "Maintenance Renewal Date".]

Some customers in this query have purchased an auto-renewal. Because there's no way to differentiate between the keys enrolled in auto-renewal and those that are not, then auto-renewal customers get reminders. They find this either (a) annoying or (b) confusing. In the cases where they are confused, they end up purchasing a renewal. When their auto-renewal runs, they believe that we have charged them twice.

There needs to be a method to differentiate between them in QLM.
Tags:
Steps To Reproduce:
Additional Information: From Soraco (edited for accuracy):

I'm not sure if you are using the User Groups (Affiliate IDs) but you could create a User Group called "AutoRenew".

From the API, Jonathan could set the is_affiliateid=AutoRenew

You can then perform a search by adding AffilateID!='AutoRenew' to the current query.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3422 [2 - Next Dev List (Holding Area)] Maintenance minor N/A 2019-08-10 22:33 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Website
Sub-Module: Data
Testing: Not Started
Summary: Get rid of the duplicate records in UltraCart (~1,000) and QLM (?)
Description: There are a lot of duplicate records left in UltraCart (and likely QLM) after the 6.6 ("QLM") release.

There are about 1,000 duplicates and there's no automated way to remove them.

I just need to slug through this.

Without this being done, we really can't automate the sync-ing of user data between the systems.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3357 [2 - Next Dev List (Holding Area)] Enhancement minor N/A 2019-06-15 19:55 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Create a method to manage operator callsigns (remove "Operator" from the My Station dialog box)
Description: I don't have much on this right now. I do have an image that I'll post.

But I wanted to get this in to at least start thinking about it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008092)
K7ZCZ   
2019-06-16 11:04   
This needs a specification and design before it can proceed
(0008099)
WA9PIE   
2019-06-16 17:00   
(Last edited: 2019-06-16 17:01)
- Create a list of operators under - Tools, Configure, Operators.
- The list would be simple - Callsign, Name. Hand entered by anyone who manages the workstation.
- The list can be common to all callsigns in the My Station dialog and can be accessed regardless of which callsign or location is behind used.
- It would be great if the user could change them without digging into a menu to select one... and that the currently selected "Operator" would be shown in main Logbook UI.

I have created a mock-up of how that might look.

Google Drive\\Shared drives\HRD Software\Attachments\OperatorField.png

Thinking it through... we should leave the "Operator" field displayed in the "My Station" tab (per Mantis 0003362).

I don't know if this is a specification or not... but let me know if more information is required.

(0008131)
K7ZCZ   
2019-06-18 13:08   
I can't say that I fully understand the impetus of the change. I'd really prefer to start with "Why" so I can understand what problem it is I'm being asked to solve. If you'd rather, I can just do what you say iteratively. But I think that approach minimizes my ability to contribute.

Let me know how you'd like to proceed. Either way, it seems like this change deserves at least more care in its design.

For now, here are the questions I have:


  • For now, I guess that the selected operator is used whenever the operator field from the selected "My Station" location and call sign would've been sued. Is that correct?

  • In other UI (like the "My Station" tab of the ALE, or the "My Station" editing dialog), what is displayed? Is the "My Station" setting simply removed, or is it offered there -- how? Can it be changed?

  • Seems like a user might creating a QSO in the ALE, then wonder what "Operator" value was going to be used. They'd have to move the ALE, look back at the main window, and check the setting there. Why not display and allow the selection of the operator from the ALE window directly?

  • Since the instructions here say the operator is displayed in the logbook's main window, it must mean that the operator is somehow associated with the operations that can be done in the main window of the logbook. What operations are those, and how does the selected operator specifically affect them?

(0008132)
WA9PIE   
2019-06-18 19:26   
Let me try to expand on this...

Think of this as a hierarchy. That is...

Customers have callsigns,
Callsigns have locations,
Locations have Operators.

Each of these can have a 1:many relationship.

So we have a method of associating a customer to callsigns as tabs in My Station. That works.

Callsigns have locations in the My Station tab. That works. The location contains the details of a station. That works.

The problem is with the way that “Operators” are handled.

A Station could have many “Operators” and some clubs absolutely will.

In the past, that caused someone to create an additional “location” or to edit “Operator” in My Station each time a different Operator made QSOs from the Station.

It would be far more elegant to provide a way to manage a list of “Operators” and give the user an easy way to change the operator without constantly going back to the My Station dialog to do it or creating a redundant location for each operator.

All that’s really needed is a way to change which operator is associated with a given QSO.

Does that help?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2578 [2 - Next Dev List (Holding Area)] Bug major always 2018-03-07 08:52 2020-07-02 02:20
Reporter: k2ie Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Ten Tec Orion II 40 meter issue
Description: I spoke to Mike about this at Orlando Hamcation...

There is a bug in the TT Orioin Rig Control code that causes Rig Control to stop working (ie not get updates from the radio) when it is tuned between a specific frequency range. It occurs when the radio is tuned between ~ 7.1467 and 7.147 MHz. The frequency field of Rig Control goes blank if the radio is tuned to that range of frequencies. If I tune away from the range, things start to work again.

To test manually, bypassing Rig Control: AF queries the current frequency. *AF sets the desired frequency. I was able to successfully set the frequency of the Orion to 7.1469 and 7.147 MHz. I was also able to properly query it. So there may be something flaky in the HRD code that causes the issue described in my post above. I cannot find any issues by sending the commands and queries directly to the radio.
Tags: Orion II, Ten-Tec
Steps To Reproduce: Turn on Ten Tec Orion/Orion II.
Set frequency of radio to 7.1468 MHz.
Connect via Rig Control.
Rig Control fails to connect.

or

With Rig Control properly connected, return radio to 7.1468 MHz. Rig Control loses connection.
Additional Information: Mike said that he suspected some frequency gap in the definition for the Orion II.

Interestingly, if I set Rig Control to the Eagle and then connect to the Orion II, frequency reads fine in that range. So a clue may be in a comparison of the frequency range code for the two radios.
Attached Files: TenTec Hex Frequency Ranges.xlsx (12,283 bytes) 2018-04-06 20:34
https://development.hamradiodeluxe.com/file_download.php?file_id=351&type=bug
Notes
(0004733)
K7ZCZ   
2018-04-06 18:24   
There are no frequency definitions in Rig Control for individual radios.

I don't think there is a way to investigate this issue without access to the radio. TenTec is no longer in business; this radio is extremely hard to find used, and when it does appear it is dearly expensive.
(0004734)
K7ZCZ   
2018-04-06 20:33   
OK, I think I've got a good theory about what's going on.

Diagnosing this without the radio is difficult. To add to the complexity is the fact that TenTec is out of business, so documentation and manuals aren't easy to find. On top of it, some documentation (and the HRD code) refers to model numbers, while other documentation (and most of our customers) refer to model names.

Without the radio, without solid documentation, I still think I have a diagnosis.

This issue is reported here against the Orion II model. I don't know if this bug affects other TenTec models or not.

As far as I can tell, the Orion II is the TenTec 566. The HRD code does not discern between the Orion (not II) and the Orion II. The Orion (not II) is model 565.

I do not have access to a programming manual for either the 566. I do have a manual for the 565, Orion (not II).

This report says that radio uses "AF" to read the frequency and "*AF" to write the frequency. This doesn't match the HRD code, which uses "?A" to read the frequency of VFO A, and "A" to set the frequency of VFO B. The HRD code does not match the programming manual, which agrees that "AF" and "*AF" should be used.

The 565 manual explains that the radio accepts both commands. They commands are not identical, however. The "A" and "?A" commands format the freuqency as ASCII letters, with a decimal, in megahertz. Tuning 7.1468 should be done by sending "*AF7.1468<cr>" to the radio.

But the radio could also be set to 7.1468 by sending "*A<6D><0D><30><cr>" to the radio.

7.1468 is in the range of problematic frequencies. Notably, the bytewise representation of the frequency involves the byte <OD>, which is the same as a carriage return. If we ask the radio its freuqency using "?A" and the radio is tuned to 7.1468 MHz, then the radio would respond with "@A<6D><0D><30><cr>".

This representation is problematic; it's the same as "@A<6D><cr><30><cr>".

In the Rig Control code, CConnection::TenTecReadFreqHertz() for any radio but the TenTec 599 (the Eagle, I believe) calls CConnection::TenTecReadHexInt() with the "?A" command and passes a parameter to the function to tell it to expect four characters.

TenTecReadHexInt() calls TenTecReadHexString() with the "?A" command and the four-count. TenTecReadHexString() has a loop which retries the commands, fiddling with some timing hacks. But it eventually calls TenTecSendString(), which sends the "?A" command string to the radio with a call to SendString().

At this point, the command has been sent, so TenTecReadHexString() calls ReadString() to read the response. ReadString() is informed of the expected four count as well as the expected terminator of the read operation, which is an 0x0D <cr> character. It turns around and calls CComPort::ReadString(), which also learns terminating <cr> character but is not told the expected length.

CComPort::ReadString() reads a byte at a time, accumulating the the bytes into an array. But it stops the first time it sees a termination character, which is <cr>.

So, it's here that things go wrong. When the radio sends "@A<6D><cr><30><cr>", the reading stops at the first <cr> character and only "@A<6D><cr>" is read. That leaves "<30><cr>" unread.

The ReadString() function doesn't return any indication of why it stopped reading. When it returns to ReadString(), that function tests the read string by looking at the last character. If the last character read is the expected terminating character, the read operation is assumed to be successful. The expected length (in our case, 4) is not considered.

ReadString() returns to TenTecReadHexString(), and things become a disaster. This function has lots of evidence of trian-and-error coding: commented out tests, messages boxes, trace messages. It's an absolute disaster of multiple code paths for different radios, and hacky little tricks to fiddle with response strings to hopefully get them to match.

Focusing on the code path for the Orion (not II) and Orion II radios, we find that the code checks to see that the response begins with "@". The repsonse is then tested to see that the command was echoed back; that we get "A" as the next character, in our specific example. Finally, the expected length is tested: if the character at the expected length (even i fthat length exceeds the length actually read -- Oops!) is 0x0D, regardless of the specified termination character, the response is ignored.

Otherwise, the response is built into a string and returned to the caller.

But because the 0x0D stopped the read early for the hex-byte representation of the frequencies that are a problem for this radio, then we have a bogus frequency response. The hacky code tries five times, fiddling with timing each time. That masks the error and slows down the UI response to the radio; it's foolish code.

This problem is local to the 40 meter band because the hex representations of the frequencies in that band are the only ones that involve an 0x0D character in them; see the attached spreadsheet.
(0004735)
K7ZCZ   
2018-04-06 20:43   
Without acccess to the radio, testing my theory is difficult. Here are possible paths forward:

1) Do nothing. That's great, because it doesn't risk breaking other radios.

2) For the Orion (not II) and Orion II only, we send the commands that use ASCII-formatted frequencies. These seem to work correctly. The fix is simple, and the change is local to the Orion (not II) and Orion II radios.

3) Make the same fix as #2, but also for other specific radios. Maybe there are some, maybe there are none.

4) Fix the issue of the expected length for all radios and all callers to the involved ReadString() functions. This probably reveals other bugs with the way the radio is handled by Rig Control, but would require exhaustive testing of features for the radios involved. Since the radios aren't available, that's unlikely.
(0004736)
k2ie   
2018-04-06 22:06   
Some thoughts:

#2 certainly sounds reasonable and I am available to test.

Or, wait until the switch to OmniRig/Hamlib type radio support and we can switch to that. Depends upon what the timeline will be.
(0004743)
K7ZCZ   
2018-04-07 08:35   
I don't know what "the switch to OmniRig/Hamlib type radio support" is.
(0004752)
k2ie   
2018-04-07 15:55   
@K7ZCZ,

Version 1.2 of the programmers manual covers both the 566 and 565. They are identical from a programming code perspective. if you don't have version 1.2 let me know and I'll upload it.

Great research on the root cause of the issue. I do have an Eagle and have not run into this issue but I can test for it if useful to the effort.

Ask Mike C. about the reference to OmniRig/Hamlib type radio support, this is something he mentioned in Orlando.
(0004811)
K7ZCZ   
2018-04-12 17:05   
Thanks for offering! That's the the version of the manual that I have, but it makes no mention of the 566.
(0004812)
K7ZCZ   
2018-04-12 17:06   
fixed (I think) with this checkin: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4051
(0004826)
k2ie   
2018-04-14 19:26   
@K7ZCZ, Mike let me know if you have something for me to test or I can catch it in the next Beta build. Thanks!
(0004851)
K7ZCZ   
2018-04-17 07:01   
I feel pretty good about the fix; if you can commit to testing this in the next beta-available build, it would be best.
(0004948)
k2ie   
2018-05-04 13:03   
Not yet fixed as of build 837.

But, the situation is improved. If I use rig control to tune the radio to a frequency in the problematic range, the radio does not change frequency and in a second or so rig control changes back to the original frequency, presumably on next read from the radio.

In the other direction, if I tune the radio to a frequency within the problematic range, rig control reflects the updated frequency.

So were seem to be halfway there.
(0004985)
k2ie   
2018-05-10 08:32   
Not yet fixed in build 839.

Starting with radio at 7.1467 MHz LSB, I attempted to use the up arrow on the 100 hz place to tune up to 7.1468 MHz. Rig control displays 7.1468 for one second after keypress, then reverts to 7.1467 MHz. Radio remains at 7.1467 Mhz.

Using VFO A physical knob on the radio, I can tune to 7.1468 Mhz and rig control properly reflects the update.

Now starting from 7.1468 MHz, if I press the up arrow, Rig Control reflects 7.1469 MHz for a second and then reverts to 7.1468 MHz. Radio remains at 7.1468 MHz.

If I use Rig Control to tune up to 7.147 MHz that works as expected.
(0004986)
K7ZCZ   
2018-05-10 09:56   
That's disappointing, though I guess a little progress is better than none. I can try to take another stab, but statically working on the code without access to the radio is very inefficient, so it's hard to give this issue much priority. This is a rare radio, and is out of production, so it doesn't feel like the effort to support it is warranted.
(0005014)
WA9PIE   
2018-05-12 01:11   
Sent it back to Assigned based on K2DLS feedback.
(0008364)
K7ZCZ   
2019-08-10 22:10   
I am unable to work on this issue without access to the radio.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2298 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2017-12-22 16:35 2020-07-02 02:20
Reporter: KC7FPF Platform:  
Assigned To: KC7FPF OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Option to print qsl label via another call
Description: When will it be possible to print on a label that qsl via a other call
When this option QSL Via is used in the logbook.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: QSL via1.jpg (49,804 bytes) 2017-12-22 16:35
https://development.hamradiodeluxe.com/file_download.php?file_id=269&type=bug
jpg
Notes
(0009489)
WA9PIE   
2019-12-05 18:27   
Kevin - I need more information. What's the use-case here?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2236 [2 - Next Dev List (Holding Area)] Bug minor always 2017-09-04 14:44 2020-07-02 02:20
Reporter: g3ucq Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Various
Testing:
Summary: Custom field reports a false positive
Description: Using the Custom 1 field I have created a field called Clublog Upload.
If I have uploaded a QSO to Clublog I add 'Yes' to the column (using bulk editor)
If I have worked a station before, and uploaded to Clublog so that Yes has been added, all subsequent QSOs with that station will show a 'Yes' for Clublog upload even though I have not yet done that.
Tags:
Steps To Reproduce: Using the Custom options create a custom field.
E.g Clublog.
For each QSO that is uploaded to Clublog add a 'YES' for the QSO.
Subsequent QSOs with the station, even on different bands/modes will show a YES against that QSO despite not having uploaded that QSO to Clublog.
Additional Information: Would it be possible to add a dedicated column for Clublog upload as for LOTW etc.?
Attached Files:
Notes
(0004494)
g3ucq   
2018-03-16 06:10   
No change.
(0007617)
g3ucq   
2019-03-07 04:37   
No change.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1963 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2016-11-15 07:27 2020-07-02 02:20
Reporter: KB3NPH Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Can't manually log frequencies above 2.3GHz
Description: Ticket #722646

In Logbook, if I hit (+) Add button to add a log entry manually, I am unable to enter a frequency in the upper microwave bands.
The data entry converts what I type in to a nonsense value.
Award tracking allows you to have entries for 6cm, 3cm, and smaller wavelengths to 1mm.
Yet you can't enter frequencies up there.
1300.000.000 is fine
2650.000.000 is fine
3500.000.000 gets mapped to 1630.032.704 which is total nonsense
5925.000.000 same nonsense
10368.100.000 gets converted to 1778.165.408 nonsense
24250.000.000 gets converted to 2775.163.520 nonsense
47000.000.000 becomes 4050.327.040 nonsense

You can also try 3.500.000.000 for example, and it converts to nonsense.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003190)
K7ZCZ   
2017-06-03 21:31   
The limit is at 2147483648 Hz, which is 2**31 - 1, which is the limit of a signed 32-bit integer. I'll see if I can figure out where we're using this data type and see what we can do ...
(0003192)
K7ZCZ   
2017-06-04 11:32   
Bad news for this one: it turns out that the limitation is essentially system wide.

1) The database is created to store frequency in a NUMBER (limited to 2^31), and should use a LONG NUMBER (with a limit of 2^63).
2) The Frequency edit control is declared to produce and store a UINT (limited to 2^32) and should use a UINT64 (with a limit of 2^64).
3) Might be an issue in XML data exchange, too, but fixing #2 would fix most of the issue with that.

This is a pretty big change, since fixing it means changing the database schema. Certainly, the team has done this before -- what mechanism do we have for migrating database schema between versions of the product, so upgrading users have their database rebuilt with the correct schema?
(0004913)
K7ZCZ   
2018-04-30 23:51   
Partially fixed with this checkin; still a lot more work to do.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4067
(0004992)
K7ZCZ   
2018-05-10 19:44   
Here's what I can think of:

1) Find all places where input is accepted from Frequency Edit control. Widen it to 64 bits.

2) Repair, rewrite, or wrap locations where 32-bit frequencies are passed with Windos messages. This will probably be the most difficult (error prone) area, since the late-bound nature of Windows messages makes it hard to get compiler verification of changes.

3) Widen communication between app components (most notably, XML files) to be sure that 64-bit values are transferred correctly.

4) Widen the Frequency and RxFrequency columns in the database. code that creates the QSO table uses FLOAT or INTEGER depending on the database vendor type (INTEGER for Access and MySQL, FLOAT for others). There is no existing schema migration code in the product applicable to this issue. We should have it for the general case.

5) Verify that comparisons and tests against frequences (bands, awards) are functioning

6) figure out how 64-bit frequencies are sent to radios; any SDRs support high frequenceis, for instances? Down converters?

Each is a couple days work, execpt for 4, which is a substantial project.
(0005170)
WA9PIE   
2018-06-01 13:20   
Verified by NT9E (one of the requesters).
(0005191)
WA9PIE   
2018-06-03 21:32   
After hearing from Mike (K7ZCZ), it seems that the Requester was incorrect when he validated this.

As a result, I'm reopening it and putting it back to Assigned status in the Current Dev project.
(0005211)
K7ZCZ   
2018-06-05 18:13   
I think that comment #4992 above enumerates most of the work that needs to be done to fully fix this issue.
(0007029)
K7ZCZ   
2019-01-19 10:27   
This checkin widens a couple of frequency formatting routines to accept 64-bit integers:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4739
(0007900)
KC7FPF   
2019-05-01 09:26   
I went through and setup and added a frequency range as suggested by Tim. Once this was accomplished. I got the same result as the customer.

Also reference ticket 685859
(0008409)
PD9FER   
2019-08-15 03:57   
Ticket #208701also marked for this Mantis issue
(0008657)
K7ZCZ   
2019-09-25 08:28   
In the team call on 2019-09-19, this issue was identified as not a priority. Note, though, that with the resolution 3181 and some of the previous check ins, this work is mostly complete.
(0008672)
KB3NPH   
2019-09-25 15:06   
If work towards a resolution has already been done, of course we don't want to discontinue working on this. Our discussion during the 2019-09-19 call again was for Mike B to set his own priority level on this. Since 3181 has been resolved and has brought us closer to a total resolution on this, it's ridiculous to halt all work on this, especially if it's noted that other issues can put us in a position to totally resolve this problem in the very near future. Our discussion on this also noted that the majority of the complaints about this issue came from European stations.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1828 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2015-11-22 00:07 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: Provide an option to use pre-defined list of US States or a user-entered list
Description: Because the US States pre-defined, we are prevented from using the same fields for creating other awards that refer to "secondary administrative areas" (in Canada, Provinces... in Russia, Oblasts... in Japan, Guns... and so on).
Tags: ParityGap
Steps To Reproduce:
Additional Information:
Attached Files: Pre-defined Lists.png (19,779 bytes) 2018-03-25 21:21
https://development.hamradiodeluxe.com/file_download.php?file_id=306&type=bug
png

WorkedAllCanada.xml (1,993 bytes) 2018-03-25 22:07
https://development.hamradiodeluxe.com/file_download.php?file_id=307&type=bug
FilterExample.PNG (41,451 bytes) 2018-03-25 22:23
https://development.hamradiodeluxe.com/file_download.php?file_id=308&type=bug
png

Primary Administrative Subdivisions.docx (62,892 bytes) 2019-02-17 11:03
https://development.hamradiodeluxe.com/file_download.php?file_id=691&type=bug
Primary Administrative Subdivisions v2.docx (64,311 bytes) 2019-02-19 20:33
https://development.hamradiodeluxe.com/file_download.php?file_id=692&type=bug
Notes
(0000674)
WA9PIE   
2015-11-22 00:11   
The awards def builder already has the ability for users (or me) to enter a list of "things". In this case, "things" would be a list of "States"... for the purpose of creating awards that use "secondary administrative areas" (in Canada, Provinces... in Russia, Oblasts... in Japan, Guns... and so on).
(0004575)
WA9PIE   
2018-03-25 21:21   
I'm adding an image that provides more information. The request was to offer an option to ignore the predefined lists. This button has no effect on the result.
(0004576)
WA9PIE   
2018-03-25 21:49   
By the way, I'd prefer that there are no pre-defined (hard-coded) lists. But no one else could figure out how to make DC part of MD for WAS. If there's a way to do that in the hand entered list of things in the awards def, I'd be happy to rewrite the few that use them.
(0004577)
WA9PIE   
2018-03-25 22:07   
(Last edited: 2018-03-25 22:11)
Here, I'm uploading an award definition file for Worked All Canada.

When this is used, it should be counting Canadian Territories by two-letter abbreviation... rather than using the US States list. It's almost like it's ignoring both frankly and not counting anything.

But you can import this one... and see that it doesn't work... as long as you have Canadian QSOs in your log where State is populated with AB
BC
MB
NB
NL
NS
NT
NU
ON
PE
QC
SK, or
YT

(0004578)
WA9PIE   
2018-03-25 22:23   
Take Ontario for example. The award def that I created shows zero (for all). But on 80m, based on this screenshot, I know I have five Canadian (DXCC=1) QSOs on 80m where COL_STATE=ON.
(0006780)
K7ZCZ   
2018-12-21 10:27   
Needs design work and clarification, so assigning this back to MikeC
(0007416)
WA9PIE   
2019-02-17 11:03   
I have added a more detailed description of the design requirements in the attached document.
(0007435)
K7ZCZ   
2019-02-19 20:33   
I've added some notes here.
(0008108)
WA9PIE   
2019-06-16 17:31   
Reading your notes, I'll put my responses here (due to the problem with attaching files right now):

It's not necessary for us to define Canadian Provinces, Guns, Oblasts... etc. We could... but that's a never-ending game. The requests will never end.

The intention of the changes we make here should enable the "Ignore Predefined Entries" box to work.

When it's unchecked, it works as designed.

When it's checked, it's not ignoring the predefined entries. As such, no one (me, other users, etc) are able to input/use their own list of "Primary Administrative Subdivisions." This can be validated with steps.

The list from 2018-03-25 22:07 can be used to test this when the box is unchecked using a log that has entries where "State" (aka. "Primary Administrative Subdivisions") are populated with Canadian provinces/territories.
(0008112)
K7ZCZ   
2019-06-16 23:20   
The repro steps are incomplete, as far as I can tell. It seems like they must provide a reference database that does (or doesn't) match the supplied province abbreviations. Is such a database available?
(0008120)
WA9PIE   
2019-06-17 14:23   
(Last edited: 2019-06-17 18:18)
Here are complete steps. I can also provide the exported awards definition:

Let's attempt to create a simple Canada awards report. These are the steps that users will take in order to create a custom report using COL_STATE:
- Launch Logbook with a log that has Canadian QSOs in it (a WA9PIE log could be used)
- Click the "Awards Tracking" tab
- Click "Definitions"
- Click "Add"
Unless specified in these steps, all other options remain at default values:
- Give it a name in the Title field: "Canada Award"
- Change "Main Field to display" to: "COL_STATE"
- In the text box below that labled "All fields:", paste the following list of the 13 Canadian Provinces and Territories:

ON
QC
NS
NB
MB
BC
PE
SK
AB
NL
NT
YT
NU

The user, or whoever is managing the award, will provide a list or a file with the valid values for COL_STATE here.

- Check the box that says, "Ignore Predefined Entries."
- Under "Definition", click the "DXCC Filter" and give it a value of 1 (for Canada)
- Up top, click "Add"
- Click the "Years" button and give it a starting date of 1/1/1945 at 12:01 AM (just to go way back)
- Where it says "Labels", type "Mixed"
- Click "Ok"
- Up top, click "Add" (again)
- Click the "Bands" button and select 160, 80, 40, 30, 20, 17, 15, 12, 10, 6"
- Click "Ok"
- Click "Ok" to close the award definition dialog box and save the award.

Then view the award.

If you get the same results I get, the award will be completely empty, but will show 13 entities needed.

What I can only assume is that the award is looking for DXCC=1 (Canada) and is looking for the predefined list of US States among the QSOs in Canada. (Obviously, I can't prove that. But I do have a log full of Canadian QSOs where the State field is filled with valid two-letter abbreviations for Canadian Provinces or Territories.

The option to "ignore predefined entries" isn't working.

(0008658)
K7ZCZ   
2019-09-25 08:36   
These steps seem dependent on some pre-existing database records being present (or not present?) It also includes vague instructions, like "if you get the same results I get" ... but doesn't clearly describe what those results are, or what they might mean.

If we want to move forward by writing code directly instead of writing a specification, I can try that -- but I do need the reference database and will probably have further questions. I might be able to take a cut at implementing the request, but I'm not perfectly comfortable doing so because I don't think we have a particularly crisp definition of what the feature is meant to do.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1705 [2 - Next Dev List (Holding Area)] Enhancement minor always 2014-08-22 13:07 2020-07-02 02:20
Reporter: user36 Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: Kenwood Radios (TS-480, 590, etc) do not display TX meters properly
Description: Meter only shows SWR on TX on Kenwood radios:

The meter select slider does not work. Selecting other than the default setting results in reversion back to the default setting upon refresh. (Note: it was verified on the TS-590S that the RMx; command to select the active meter does not work and results in a ?; error code. The published specs seem to be wrong.

*** Recommend changing the Layout for newer Kenwood radios to show SWR, ALC and Comp, similar to Yaesu. The RM; interrogation command returns the levels for all three in the same response. ***
Tags: Kenwood, TS-2000, TS-480, TS-590, TS-890S, TS-990
Steps To Reproduce: Using a Kenwood TS-590S (or 480; other radios likely too):
- Open Rig Control and connect to the radio
- Select TX
- Observe the power meter shows SWR
- Go to Tools->Customize Layout, then open the Sliders: Layout tab
- On a blank slider option, select Meters
- Close the Options Tab
- Try to select a meter setting different than the default using the slider
Additional Information: *** May also apply to all Kenwood radios with RM; commands, such as TS-570, TS-2000, TS-990 ***
Attached Files:
Notes
(0004248)
K7ZCZ   
2017-09-20 10:35   
This issue turns out to be pretty involved, and is the intersection of three different problems.

Problem #1: No round-trip of visible meters state disrupts the "Meter" slider

The "Meter" slider lets the user select of the available secondary meter settings on a radio. For some Kenwood radios (like the TS-480 and TS-590), the physical meter on the radio shows signal strength ("S meter"), and a secondary meter shows any one of a few configurable settings: SWR, compression, or ALC. Some radios have more choices; the TS-990 additionally offers ID, VD, and Temperature, for example.

The architecture of the rig control app is such that it handles sliders by sending a command to make a setting, then send another command to read the same setting back from the radio. This is a sensible approach becaue reading the actual state back from the radio confirms that the screen represents the actual state of the radio. If the radio misses the command, or the user physically interacts with the radio to change the state, then the visible state in the UI is corrected on the next update. More specifically, the design is such that the rig control application doesn't maintain it's own copy of the state of the radio.

The Kenwood radios use the "RM" command to set the state of the meter. RM accepts an integer parameter to turn the radio to a particular meter type; RM1 sets the TS-480 radios to SWR, for example. Rig Control would send "RM1" if the user moved the "Meter" slider to the "SWR" position.

On the next update of the radio status, Rig Control will use the "RM" command to query the radio to see which meter mode has been selected. Unfortunately, the "RM" command does not report the currently selected meter mode. Instead, it sends a series of replies that indicate the value of each meter reading. On a TS-480, the single "RM;" query command gets a response like this:

RM10010;RM20005;RM30002;

which indicates readings of 10/10 for SWR, 5/10 for compression, and 2/10 for ALC.

The RM query response gives the meter readings, but does NOT give the state of the meter display. Nothing in the response indicates that the physical radio is presently showing the "compression" reading, for example.

Thus, when Rig Control reads this command's output, it doesn't know what the display is showing. It misinterprets the response as "1" and the visible meter slider reverts to the corresponding "SWR" setting even though the radio might be showing something else. Notably, some Kenwood radios (like the TS-990) provide the MT; command, which reads and sets the displayed meter type.

Note further that the meters involved are mostly transmit-only parameters. When not transmitting, the values are 0 -- no power, no compression, no ALC is active when listening. In TX, these values are dynamic with the input signal.



Problem #2: One or Two S meter displays in Rig Control?

While the radio displays two meters, only one is shown in Rig Control. Some radios DO show two meters, but these radios have dual front-ends (not dual VCOs) and can simultaneously show two S meters. The request that two meters be shown (Mantis 1320) is possible, but it doesn't match the general architecture of Rig Control, which shows two meters only for radios with two S-meters.

There's at least a little bit of confusion in the UI about "two meters" meaning two S-meters, or one S-meter and one selectable TX-parameter meter. Conceivably, we should offer two or three meters in the UI to display one (or two) S-meters, plus one of the confgurable TX-parameter meters.


Problem #3: Representation of TX-only parameters

Since the secondary meters are mostly TX-only parameters, a setting in the software allows the configuration of the two displayed meters. The setting in question is reachable using the "Customize" button in Rig Control, then activating the "Meters" tab in the resulting "Customize Layout" dialog. In that window, a "S Meter - TX mode" group box contains two drop down controls for the "Main" and "Sub" meters, and offers various choices for the parameter to be displayed in each meter.

This UI is problematic for a few reasons. First, it is global; it affects all radio connections, and isn't set on a per-radio or per-connection basis. Because of its global scope, the next problem is that the dialog isn't aware of the connected radio and implies that there will always be two visible meters in the UI of the radio.

The description in the UI says that the secondary display, for TS-2000 and TS-480 radios, will be based on the setting of the "Meter" slider. However, since the meter slider state isn't reliable because of the missing query command (Problem #1 above), this scheme simply doesn't work. And it's also not too practical for users who have radios (like the TS-480 )


Possible solutions:

Note that the architecture of Rig Control works fine for radios which do allow the reading of the selected, visible meter type. (I don't have a TS-990 to test with, but even if it doesn't work, it could be made to do so by using its MT command instead of the RM command to read the state of the radio.) Radios like the Yaesu FT-450D have a secondary meter and the meter slider works correctly, since the state of the radio's selected secondary meter is both settable and readable using CAT commands.

For radios without CAT command support to query the configured meter, I think we have two choices:

Solution #1: Modify Rig Control to NOT support the meter slider for these radios -- it can't be made to work without the required CAT command. Instead, we can offer one or more configurable secondary meters. The user can choose one in the Rig Control UI, but it won't follow the physical setting in the radio. This does resolve the customer request of showing the dynamic, transmit-only measurement from the radio.

Solution #2: Modify Rig Control to show any number of additional meters at the user's discretion. The user can then configure whatever they want (that the radio supports) and dynamically show multiple TX parameters at the same time. Kenwood's own ARCP-480 software does something like this; it displays meters for all three TX parameters, plus the S-meter.

Solution #3: Maybe there are other ideas ... ?

The two identified solutions don't rely on being able to read the selected meter state from the radio, so they're implementable for any radio. A decision would need to be made about applying the solution to all radios, only some (just the radios without readable meter type settings).
(0007230)
K7ZCZ   
2019-02-02 22:59   
setting to feedback to see if we can make some progress on the decisions outlined here. It's been more than four months ...
(0007689)
K7ZCZ   
2019-03-16 20:05   
Nobody to assign for feedback because the reporter is a strike-through account. It's been sitting around for several months.
(0007732)
WA9PIE   
2019-03-24 23:23   
If a given rig doesn't have a command to support the query of a configured meter, then I think solution #1 is the right approach. It solves the problem and (I think) solution #2 introduces complexity we don't need right now.
(0008245)
K7ZCZ   
2019-07-17 17:12   
The work I've done on the TS-890 has revealed some more information.

Unlike the TS-480, the TS-890 does *not* give multiple responses to a single "RM" command, even though the manuals for both radios imply that they would work the same way. I've added some code to the Rig Control application to make the TS-890 work mostly as expected: rig control will show the meter selected on the front panel. This is facilitated by the availability of an "MT" command on the TS-890 and TS-990. The MT commnad reports identity of the selected meter. It appears that other TS-model radios from Kenwood don't support this feature, so for those radios we're in the same boat.

One next step for this issue woudl be to remove the "transmit meter" buttons from the options screen. They're not actually connected to anything -- or, more accurately, they're connected to code that doesn't actually work.

The changes for the TS-890 and TS-990 are in this change list, in the 6.7 branch of the product:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5077

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3679 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2020-05-14 23:24 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Import Export
Testing: Not Started
Summary: Investigate issues with importing ADIFs that have type M (MultilineString) addresses
Description: We have the following reports on this topic:
https://support.hamradiodeluxe.com/scp/tickets.php?id=40258
https://forums.hamradiodeluxe.com/node/48455

The report indicates that MultiString fields are not being properly parsed on import.

The purpose of this is to investigate this report.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3667 [2 - Next Dev List (Holding Area)] Enhancement feature N/A 2020-04-10 03:47 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: ALE Window
Testing: Not Started
Summary: Add "quick ALE" to Satellite Tracking application
Description: Because of the speed of QSOs during satellite passes, it's not useful to task back-n-forth between the Satellite Tracking and Logbook.

This change would add an ALE to the Satellite Tracking app (similar to DM-780) that provides the ability to (a) do a callsign lookup and (b) entry/display of common fields important for satellite QSOs.

mock-up attached; illustrative
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: SatelliteALE (detail).png (961,119 bytes) 2020-04-10 03:47
https://development.hamradiodeluxe.com/file_download.php?file_id=952&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3664 [2 - Next Dev List (Holding Area)] Enhancement minor N/A 2020-04-10 03:04 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: LoTW
Testing: Not Started
Summary: Add option to automatically select QSOs for LOTW upload when Queued
Description: Customers have asked us to enable automated QSO uploads to LOTW (similar to what's being done with other online logging tools). The problem with doing it automatically is that LOTW does not have any ability that would enable customers to remove entries that have incorrect information (all other online logging/confirmation tools enable this).

As an interim approach, we should add an option that would upload all QSOs where the QSL Sent status = Queued

(QSL Sent status can already be set to Queued (image attached). This change would just create an option for the user to upload all the QSOs that haven't already been uploaded, without the need to select them.)

Mock-up of LOTW upload option attached.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ALE-Options-QSL Defaults.PNG (14,288 bytes) 2020-04-10 03:04
https://development.hamradiodeluxe.com/file_download.php?file_id=950&type=bug
png

Queued.png (36,552 bytes) 2020-04-10 03:04
https://development.hamradiodeluxe.com/file_download.php?file_id=951&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3442 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-08-28 02:19 2020-07-02 02:20
Reporter: PD9FER Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Label Printing uses wrong data for Callsign
Description: When printing a QSL card, it's using the Callsign associated with the key rather than the Callsign associated with the QSO.
So... if you imported QSOs from way back when your Novice call was WN9PIE... and the Callsign in the QSO is WN9PIE... then the QSL card says, WA9PIE.
That's a bug.
Tags:
Steps To Reproduce: N/A
Additional Information: On Request from WA9PIE pse assign to Doug
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1894 [2 - Next Dev List (Holding Area)] Enhancement feature have not tried 2016-03-29 08:35 2020-07-02 02:20
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Printing extra items on a label
Description: Ticket#322140
Two lines print Ok but if I add extra items such as Rig, Ant etc then the new items just extend the first two lines beyond the label boundries of the specified label.
There is plenty room on the label; to add more lines for items but the software does not provide for a line feed.
Tags:
Steps To Reproduce:
Additional Information: This guy wants to print on labels what is normally printed on pre-printed QSL cards. I think he is asking too much to be printed on the labels which isn't necessary.
Attached Files: QSL Label.jpg (66,363 bytes) 2016-03-29 10:20
https://development.hamradiodeluxe.com/file_download.php?file_id=78&type=bug
jpg
Notes
(0000746)
KB3NPH   
2016-03-29 10:17   
Customer send an image of the type of label he wanted to print with HRD. Please see attachment.
(0007795)
WA9PIE   
2019-03-30 05:32   
I'll consider this at a later point.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1834 [2 - Next Dev List (Holding Area)] Enhancement feature have not tried 2015-12-03 09:15 2020-07-02 02:20
Reporter: KB3NPH Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module:
Testing: Not Started
Summary: Selectable Date Format in QSL Labels
Description: Ticket# 101724
I would like to print QSL labels in the format "01 DEC 2015" instead of the default "12/1/15".
I tried changing my system prefs, which changed the format in Logbook to show 01-DEC-15, but when trying to print a QSL label, it shows the date as "01-15-00" Is there a method to have date show the month in text instead of numeric; and to show the full year?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000680)
KB3NPH   
2015-12-03 12:35   
By way of further explanation, US format is MM/DD/YY, while most of the rest of the world indicates DD/MM/YY. 12/1/15 can be interpreted as 12 January 2015 or 1 December 2015. Common recommendations for QSLS are to format date as DD/MMM/YY to avoid confusion, with the month being text rather than numeric. I would appreciate either ran enhancement or workaround that allows me to print labels in that manner.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1800 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2015-10-15 06:03 2020-07-02 02:20
Reporter: user47 Platform:  
Assigned To: DOUG OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Dymo label print issue
Description: I get a wrong format for my choosen label

Your size is DYMO 99012 = 83.8mm x 25.4mm

The warning is : Defined Labels are larger than the paper size

It must be DYMO 99012 = 89mm x 36mm ( so it wrinten on the official box in the Netherlands )

after changing it the program it still say my label won't fit ....

I can print ( Dymo 330 Turbo ) but i need to change it every time

Where can change te size so i wont get a warning ???


Thanks 73 Rene PA3CQF
Tags:
Steps To Reproduce: Try to print - gets error message -Defined Labels are larger than the paper size.
Additional Information: .. ticket 115866
Attached Files:
Notes
(0009509)
KC7FPF   
2019-12-19 11:34   
Some more related issue for this item. Via OS ticket 284191

https://www.youtube.com/watch?v=w3J7UU8OLsY&feature=youtu.be

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1663 [2 - Next Dev List (Holding Area)] Enhancement major have not tried 2014-07-02 22:09 2020-07-02 02:20
Reporter: WA9PIE Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Satellite QSOs do not contain the correct fields for LOTW and not recognized
Description: Ticket #705520

I talked to Mike WA9PIE at Dayton about my problem. He gave me his card but his email address does not work as I get the email back undelivered. The problem is that when I upload QSOs to LOTW the satellite QSOs do not arrive. Refer to the attachment and you can see there are 5 QSOs that do not get accepted. There are no error reports from LOTW. I talked to the LOTW booth at Dayton and they said it is a HRD issue. I showed the problem to Mike using an example of how I do my log and he said for me to remind him after Dayton.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004275)
PD9FER   
2017-10-29 02:59   
More alike tickets coming in

Ticket #830370
COL_BAND_RX was populated in the past, but not for all recent QSOS. Now COL_FREQ_RX is correctly populated with the frequency but COL_BAND_RX is empty instead of having 70cm or 2m etc.
Propagation should be SAT, I believe, for EQSL and other purposes, not "Satellit"

Ticket #662847
Eqsl upload as also LOTW etc. Should bring uplink frequency as main frequency to be uploaded for the QSO. HRD instead uploads downlink RX frequency and this can result in no matching QSOs. Also the field propagation type shouldn't be written by HRD with the statement 'Satellit' which I think can be wrong for LOTW and EQSL
For these two reasons QSO may go on direct QSO instead of SAT and on wrong band /mode
(0004289)
PD9FER   
2017-12-12 04:16   
Also reported via Ticket #113565

PROP_MODE not Being SAT whilst it is Entered,
(0004330)
PD9FER   
2018-02-28 07:11   
Another one.. Ticket #138950
(0006336)
PD9FER   
2018-10-23 06:23   
And once more Ticket #152674
(0007960)
K7ZCZ   
2019-05-30 16:52   
Switched to "enhnacement" per the team call on 2019-05-30
(0009012)
K7ZCZ   
2019-10-25 03:35   
There's just some incomplete notes here -- nothing clear or directly actionable. The description mentions attachments and there are no files here.

Maybe this is a dupe of 3142, but it's nothing that can be approached now due to the lack of detail and clarity in the report.
(0009015)
PD9FER   
2019-10-25 05:07   
I agree 3142 is Duplicate but has more information in it.
(0009207)
WA9PIE   
2019-11-08 02:28   
I'll take this until we sort out the detail.
(0009534)
PD9FER   
2020-01-05 12:23   
New details in Ticket #619437
(0009541)
PD9FER   
2020-01-09 13:07   
Getting more and more angry tickets on this.
It should be an easy fix though.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1649 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2014-06-10 18:35 2020-07-02 02:20
Reporter: user36 Platform:  
Assigned To: DOUG OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Logbook - Problems with Brother QL-700 and DK-11201 Labels
Description: Trying to print in this combination locks up Logbook and requires a restart of Logbook to continue.
Tags:
Steps To Reproduce: See Additional Information.
Additional Information: Refer to ticket 483836.

QSL Label Printer Issues
Release date 05/15/2014
Version 6.2.3.271
Operation system Windows 8.1. 64 bit
Printer Brother QL-570 & QL-700 with labels DK-11201
Label Printing Issue still with HRD v6.2 RC 2 – 267
I’m still having issues printing QSL labels with the latest release. I was hoping that this would have been
sorted with this latest release Version 6.2.3.271.
OK here are the problem issues I have found when trying to print labels.
Deleting the LabelDefs.xml has no effect.
In Logbook – Print Setup. If you have more than one printer on your system your selection is not saved and next time you start the logbook program the setting reverts to the computers selected default printer not
HRD’s.
In Logbook – Print Labels – Print Tab - Selecting Label Printer. This does not save the selected printer if more than one printer is installed on the computer. The selection field always reverts back to the computers
default printer each time the print labels are selected from start-up. My label printer is not the default
printer.
File – Print Labels – Print Tab – select my label printer (QL-570 or QL 700 which is a single label printer) – the
right label section shows 4 labels where it should be one.
When I try to print an Address or QSL label I see at the top of the window “Labels (Not Responding)” the
window greys out and locks up the logbook program and I have to restart the logbook program again to use it.
When you open active printers is showing that it is spooling continues.
I have copied the old settings from version v6.1.4.189 release 6.1.4 that works on my Windows 8.1. 64 bit.
When v6.2 RC 2 – 267 version of the program with these settings entered still have the same issue.
I seem to remember that there were issues with HRD some time ago regards the US and UK windows installation. I wonder if this is happening here.
I have tried installing over the old versions and uninstalled everything and installed the latest version and this does not resolve the issue with Version 6.2.3.271.
I can still only run v6.1.4.189 release 6.1.4 on the computer when installed to enable me to have the label
printing facility.
I don’t think it’s the printer driver as it worked with v6.1.4.189 release 6.1.4 and other programs that use the printer so I assume that this is OK.
If any of the HRD programmers need a computer with the Brother QL-700 printer attached with the DK-11201 labels to experiment I will be very happy to give them full control of the computer via remote access.
---
06/03/2014 9:29 pm Jason Boyer
Hello Ian,

If you're up to reinstalling 6.2 again, I suggest backing up your logbook, and saving your settings per the Archive function as detailed in the HRD Manual. Once that is complete, rename or delete the folder C:\Program Data\HRDLLC and reinstall HRD 6.2. That will force HRD to use default settings for labels and
may resolve your printer issues.
---
06/10/2014 12:50 pm
As you asked me to do I did uninstall my old version (6.1.4.189) from my computer and done a fresh of HRD
6.2.3.271 but it was no good as it made any difference.
I also checked my Brother Ql-700 printer driver was up to date; it was as I checked on the Brother website.
Deleting the LabelDefs.xml has no effect. When you open active printers is showing that it is spooling continues. When I try to print an Address or QSL label I see at the top of the window “Labels (Not Responding)” the window greys out and locks up the logbook program and I have to restart the logbook program again to use it.
I have tried all that I can.
I know what I am at, as I am a computer tech and fix Home computer for a living.
There seems to be something wrong with the HRD label printing. If any of the HRD programmers need a computer with the Brother QL-700 printer attached with the DK-11201 labels to experiment I will be very happy to give them full control of the computer via remote access.
Just let me know and I will take 6.1.4.189 off again and put 6.2.3.271 for them to work at. I have Skype and TeamViewer on my pc.
Attached Files:
Notes
(0000625)
WA9PIE   
2015-10-01 13:41   
The following trouble ticket is related to this bug.

http://tickets.hrdsoftwarellc.com/scp/tickets.php?id=1377

It was assigned to Erik. I'm closing the trouble ticket and sending the bug tracking number.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1572 [2 - Next Dev List (Holding Area)] Bug major always 2014-02-04 10:35 2020-07-02 02:20
Reporter: w4ase Platform:  
Assigned To: WA9PIE OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: QSO Window
Testing: Not Started
Summary: DM-780 Mouse over in waterfall not following the mode for decode
Description: When you have selected a stream to decode in the RX window you can then move your mouse over another stream on the waterfall and a pop up window will decode it. This works great in PSK-31 - but not in other PSK, RTTY or CW modes - the mode for the mouse over seems to be stuck in a PSK-31 mode. This use to work for all modes.
Tags:
Steps To Reproduce: select a PSK-31 stream to decode in RX window - move mouse to another stream - pop up window will decode - now try a different mode like RTTY - it will not decode - pop up window comes up but decodes garbage
Additional Information:
Attached Files:
Notes
(0005452)
g3ucq   
2018-06-24 15:15   
This was reported in another Issue. Not fixed.
(0005792)
WA9PIE   
2018-07-25 12:53   
Updating these to Feedback, as all have questions or need re-tested.
(0005824)
g3ucq   
2018-07-25 14:16   
PSK31 and PSK63 decide OK in the pop out but not CW. No rtty signals. to test
(0005828)
w4ase   
2018-07-25 16:24   
I was able to test a number of modes and it is working as it should - Thanks - nice to have this feature back again. It has been gone so long that most people do not know it every existed. Some in the marketing business might even say it's a NEW FEATURE
(0005833)
g3ucq   
2018-07-26 02:18   
For me CW is decoded in the DM780 rx window but not from a pop out on the waterfall.
(0007666)
WA9PIE   
2019-03-10 20:51   
See Mantis 1572 and Mantis 1789

Hover over (mouse over) a digital signal in the waterfall to get a pop up bubble with decoded message. Very handy. You do not need to even click on the signal - just hover. Used to work in PSK31, PSK63 modes and in RTTY. Now stuck in PSK31 mode only.

Still not fixed even though this broke in 2014. Was working in all modes in v5 and several early versions of 6.0

See these videos to describe the issue. You can see how valuable this feature was in contests.

https://photos.app.goo.gl/iLabkVPn1TQTVfu57

https://photos.app.goo.gl/nU8wXrvHyTTANrBs5


Thanks and 73! Howard W6HDG
(0007667)
WA9PIE   
2019-03-10 20:55   
This issue was fixed a number of versions ago and then broke again. Several of us have reported it as a feature that was lost in the shuffle over the years

Mike, I showed this to you once when you logged into my computer to look at another issue we were having – I think old versions not clearing themselves with a new install – It is almost hard to test today as the PSK traffic, due to FT-8, is all but nonexistent. It would take a RTTY contest to test fully.

Here is the problem as concise as I can make it.

Much Older versions – back in the v5 days:

In DM-780 you could be decoding a RTTY signal and have the “M” marker on that station and see the decode in the RX window. Then you could move your mouse and “Hover” or also called “Mouse Over” to another stream on the waterfall, while leaving the “M” line alone, and a popup window would appear and also decode that signal – so you could see your original decode in the RX window and the Mouse Over decode in the Pop Up window - this was helpful in looking for the next contact in a contest or trying to judge where you want to go next. And yes, Super Sweeper will do this, but this was a quick way to look at one station and see who it was. People also found that Supper Sweeper was not as good when bogged down with 30 or 40 decodes in a contest.

 At some point the Hover or Mouse Over got stuck in PSK-31 – regardless what mode you were decoding in the RX window, the Hover or Mouse Over function was stuck and only wanted to decode PSK-31. It would not follow the main decode mode selection.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2792 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-29 20:52 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: user81 OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.4.0.858  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Digital Master: PSK Propagation Reporter options help has links to old website
Description: The online help in the "PSK Propagation Reporter" options dialog still references hb9drv.ch
Tags:
Steps To Reproduce: 1) Fire up DM
2) Use the "Options" command in the "Logbook" menu
3) In the resulting "Program Options", click "PSK Reporter..." in the left-hand column
4) In the resulting "PSK Propagation Options" dialog, read the text.

BUG#1) Several mentions of hb9drv.ch
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2790 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-29 17:00 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.858  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Documentation: does not explain use or function of "Logbook" tab in ALE
Description:
The documentation acknowledges that the "Logbook" tab in the ALE exists, but does not describe its behaviour or intended application.

Specifically:

1) When should it be populated?
2) What is the difference between "All", "Partial", and "Exact"?
3) What do to the other buttons in its toolbar do?
Tags:
Steps To Reproduce:
Check out the logbook tab docs here:
https://wiki.hamradiodeluxe.com/index.php?title=Logbook#Logbook_Tab

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2784 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-25 10:45 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Logbook: Callsign Lookup configuration doesn't Test Logbook database itself
Description:
The "Callsign Lookup" confguration allows users to test the callsign lookup configuration with a callsign of their chosing. But it doesn't fully demonstrate the feature; it doesn't look at the local country database or the Logbook itself, effectively ignoring options that the users has set. What's the point of testing a configuration if the specific configuration the user has supplied wasn't actually tested?
Tags:
Steps To Reproduce:

1) Start up the Logbook
2) Configure only a new database. No other databases should be configured; that is, not only not opened, but not set up for the logbook to open.
3) Use the "Callsign Lookup" command to edit the Callsign Lookup settings so that the methods enabled match the defaults shown in the attached "defaults" screenshot.
4) In the Empty database, use the ALE to add a new entry
5) In the ALE window, enter the callsign "F5JD". Press TAB (or click the "Lookup" button) to lookup the callsign. At this point, the database is empty, so the lookup will end up being resolved by QRZ. Note that the lookup correctly finds "Jose", with accent aigu on the E.

6) Before saving the entry, edit it so that Jose's name is incorrectly spelled. I guess we could make it exactly match the c-circumflex reported here, but it's easy enough to enter "Josxxx". Remember to edit Jose's mailing address on the "Location" tab, too. When you're done, the ALE should look something like the attached screen shot (with different dates and times).

7) Press "add" to save that entry

8) Use the "Callsign Lookup" command in the "Configuration" menu to get to the configuration UI. On the "Enable" tab, disable the QRZ lookup so that "Logbook" and "Country List" are the only enabled meethods. This hsould look like the "NoQRZ" screenshot, attached.
9) In the "Callsign Lookup" dialog, activate the "Lookup Options" tab.
10) On the "Lookup Options" tab, enter "F5JD" in the test callsign field, and press "Lookup".


BUG#1) No record is found. The test check the actual configuration -- it ignores both the Logbook and Country List methods that were configured.
Additional Information:
System Description
Attached Files: CallsignLookupConfigNoQRZ.png (24,942 bytes) 2018-06-25 10:45
https://development.hamradiodeluxe.com/file_download.php?file_id=445&type=bug
png

CallsignLookupConfig.png (26,165 bytes) 2018-06-25 10:45
https://development.hamradiodeluxe.com/file_download.php?file_id=446&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2783 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-25 10:33 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: new Product Version: 6.4.0.846  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Logbook: Logbook Layout "C" doesn't seem to work
Description:
The Logbook's toolbar has "A" and "B" buttons to activate layouts "A" and "B". The Logbook appears to support a third "Layout C", but there is no button on the toolbar for Layout C.

In the View menu, there's a "Layout" tear-off which includes "Layout C" and "SAve Layout C" commands. The "Save Layout C" command appears to be always disabeld.

Perhaps Layout C should be completely removed, or maybe it's meant to be supported and the menu command should be disabled.

How do we figure out what the intended functionality is?
Tags:
Steps To Reproduce: 1) Start up the Logbook
BUG#1) Observe the main toolbar; no "C" button

2) Exercise the "Layout" tear-off in the "View" menu.
BUG#2) "Save Layout C" is always disabled


Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2782 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-23 15:05 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.846  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Documentation: Logbook Callsign Lookup setting is ambiguous
Description: The logbook allows several sources to be configured to perform callsign lookups. One of the sources is the Logbook itself; previously resolved QSOs will be used to satisfy future requests for the same callsign.

USers will not find this setting clear, as the setting makes no mention of which Logbook database will be used. Is it the "HRD" default database? The currently open database? What if more than one database is open -- are all considered? In which order? Is it the database configured as the default in the "Network Server" settings?

This feature should be clarified. The documentation says nothing of the behavior.
Tags:
Steps To Reproduce: The documentation section in question is here:
https://wiki.hamradiodeluxe.com/index.php?title=Logbook#Lookup_Options

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2781 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-06-23 11:30 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.846  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Logbook: DX Cluster "Layout" tab allows, then ignores, column rename operation
Description: Seems like the DX Cluster "Layout" feature is meant to allow the renaming of columns. But it doesn't work.

Maybe this feature has some other intended use, but the documentation does not provide any explanation of what's meant to happen here.
Tags:
Steps To Reproduce: 1) Start up the Logbook
2) Open your favorite database
3) Use the "Display" command in the "DX Cluster" tear-off in the "View" menu to assure the DX Cluster window is displayed
4) Use the "Options" button in the toolbar of the "DX Cluster" window
5) In the resulting "DX Cluster Options" dialog, activate the "Layout" tab
6) In the Layout tab, double-click any column name in the right-hand side "selected" list
7) The entry turns to an editable field. Type in anything you'd like here: "fooey", for example.
8) Press "OK" di accept the canges and close the window

BUG#1) The layout of the window's columns doesn't change. No error is given.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2780 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-23 11:21 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Documentation: incorrectly describes "Your Information" tab in Logbook's DX Options page
Description:

This topic describes the "Your Information" tab of the DX Cluster options window:
https://wiki.hamradiodeluxe.com/index.php?title=Logbook#Your_Information

It says that the grid square shouldn't be used to change the location. It doesn't need to say that, as that's impossible: the grid square edit field in this window is read-only. The documentation should be updated to correctly describe the product.
Tags:
Steps To Reproduce:
Additional Information: Note that the dependent issue suggests removing the "Your Information" tab altogether. If the tab is removed, the documentation should be updated to simply remove this section, since the tab is gone.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2777 [2 - Next Dev List (Holding Area)] Bug minor always 2018-06-21 15:17 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Logbook: Consider removing the "Your Information" tab from DX Cluster Options dialog
Description: The "Your Information" tab in the "DX Cluster Options" window appears to me to be completely redundant.

The tab contains a "Region" group box with buttons that are the same as the "Region" buttons on the "Selection" tab.

The "Locator" control isn't editable. The Greyline display shows a greyline that's also visible on the main window by clicking the "Display" command of the "Greyline" tear-off in the "View" menu.

It would be best to delete this page, I think.
Tags:
Steps To Reproduce: 1) Fire up the logbook
2) Whatever database you've got handy is fine
3) Use the "Options" command in the DX Cluster toolbar
4) In the resulting "DX Cluster Options" window, activate the "Your Information" tab; it's the last one.

The "Selection" tab is in the same "DX Cluster Options" window.
Additional Information:
Attached Files: YourInformation.png (98,316 bytes) 2018-06-21 15:17
https://development.hamradiodeluxe.com/file_download.php?file_id=433&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2766 [2 - Next Dev List (Holding Area)] Bug crash always 2018-06-12 19:54 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Label
Testing: Not Started
Summary: Logbook: Crashes before printing labels for a record with no callsign
Description: Attempting to print labels for a list of records that includes one more more records with a no call sign causes the Logbook to crash.
Tags:
Steps To Reproduce:
First, you'll need to create a record with no callsign.

1) Fire up the logbook
2) Open your favorite database. You'll need other records in addition to the blank we're about to create.
3) Use the "Add" button in the toolbar to add a record.
4) Give it a callsign. Add whatever else you'd like to the record.
5) Press "Add" to save it and close the ALE.
6) Open the record you created again by double-clicking on it.
7) Delete the callsign from the "Callsign:" field in the ALE
8) Save the record by pressing the "Update" button in the ALE.

Now that we've got a record without a callsign, let's try to print it.

9) Highlight the record without a callsign, but also highlight additional records.
10) Right click on it. In the resulting context menu, use the "File" tear off to reach the "Print" tear off, and select the "Labels" button.

Nothing further; the resulting printing settings dialog will try to sort the list of selected records by callsign, and deferences the empty callsign.

The call stack is shown here:


>	HRDLogbook.exe!CLabelSheet::OnTimer(unsigned int nIDEvent=0) Line 524	C++
     HRDLogbook.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam=1, long lParam=0, long * pResult=0x01d6f6cc) Line 2440	C++
     HRDLogbook.exe!CWnd::WindowProc(unsigned int message=275, unsigned int wParam=1, long lParam=0) Line 2094	C++
     HRDLogbook.exe!AfxCallWndProc(CWnd * pWnd=0x1ae39d00, HWND__ * hWnd=0x003603ba, unsigned int nMsg=275, unsigned int wParam=1, long lParam=0) Line 285	C++
     HRDLogbook.exe!AfxWndProc(HWND__ * hWnd=0x003603ba, unsigned int nMsg=275, unsigned int wParam=1, long lParam=0) Line 434	C++
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!DispatchMessageWorker()	Unknown
     user32.dll!_DispatchMessageW@4()	Unknown
     HRDLogbook.exe!AfxInternalPumpMessage() Line 183	C++
     HRDLogbook.exe!AfxWinMain(HINSTANCE__ * hInstance=0x0045d0fc, HINSTANCE__ * hPrevInstance=0x0000000a, wchar_t * lpCmdLine=0x00000000, int nCmdShow=30865800) Line 47	C++
     HRDLogbook.exe!__tmainCRTStartup() Line 251	C
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2764 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-06-10 22:35 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Serial Port Server: won't start from command line
Description: I'm unable to get the HRD Serial Port Server to do anything from the command line.

Tags:
Steps To Reproduce:
1) Run from the command line; should be able to use /Remove, /Debug, /Start options from the command line, even when not running as a service.
2) Examine the log file
BUG#1) Always contains this message:

[Sun Jun 10 20:33:08 2018] Exit function
Error starting Service Control Dispatcher
=========================================
Status code ...: 1063
Status text ...: The service process could not connect to the service controller.

[Sun Jun 10 20:33:52 2018] Exit function
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2763 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-06-10 22:19 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.842  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Serial Port Server: opens log file exclusively
Description: The serial port server writes to a log file with a name like "HRD-SerialPortSvr-YYMM-June-YYYY.txt"

This file is locked for reading while the serial port service is running. The exclusive lock prevents other processes from reading the file. That makes the log file pretty useless, since a user must stop the process to examine the log file and learn the state of the process.
Tags:
Steps To Reproduce: 1) Start the serial port service
2) Find the log file. It's in the C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe directory, by default.
3) use the "Type" command to try to look at the file.

BUG#1) It doesn't work because the file is locked for read by the serial port service process itself.

C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe>type HRD-SerialPortSvr-1806-June-2018.txt
The process cannot access the file because it is being used by another process.


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2762 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-06-10 22:14 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.842  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: Serial Port Server: config file is dated
Description: The default serial port service config file is very dated. It has an outdated copyright message and an incorrect list of supported operating systems.

The content of this file should be reviewed and updated.
Tags:
Steps To Reproduce: Examine the default HRDSerialPortSvr.cfg file. The first few lines of the file are pasted below.

Additional Information:
#
#   Ham Radio Deluxe Serial Port Server
#   -----------------------------------
#
#   Copright (c) 2006 by Simon Brown, HB9DRV.
#
#   Note: this only runs on Windows NT/2K/XP. It does not run
#   on Windows 95/98/ME/SE.
#
#   This file defines the configuration of the Remote Access Server.
#   The format of each entry is TOKEN = VALUE. 
#
#   Supported tokens
#   ----------------
#   COM
#   PORT
#   USER1 to USER20
#   WELCOME
#
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2757 [2 - Next Dev List (Holding Area)] Maintenance major have not tried 2018-06-01 12:19 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.842  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: Not Started
Summary: Maintenance: Consider dropping support for Windows 7
Description:
We currently claim to support Windows 7, Windows 8.x, and Windows 10. We claim to support both 32- and 64-bit versions of these operating systems.

Supporting three (six, really) operating systems is a heavy burden. These OSes aren't represented well on the development team or the beta team.

We should consider immediately dropping support for Windows 7 to save time and effort.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2747 [2 - Next Dev List (Holding Area)] Bug minor always 2018-05-25 22:15 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: Installation section uses out-dated screen shots
Description:
The documentation shows a very old UI for setup. These differences are more than cosmetic. The documentation is missing steps and shows steps out of order. Some of the cosmetic differences are so substantial that they're hard to recognize. The difference between the documentation and UI is probably confusing to users and doesn't provide a good out-of-the-box experience.

Tags:
Steps To Reproduce:
1) Visit the "installation" section of the documentation. This URL goes there: https://wiki.hamradiodeluxe.com/index.php?title=Introduction#Installation

2) Compare the screen shots to a real, live HRD setup instance. They're very different; several steps are missing and the program is poorly represented in its own documentation.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2730 [2 - Next Dev List (Holding Area)] Bug minor always 2018-05-20 23:49 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: "Synchronizer" documentation anachronistically includes Serial Port Server config file
Description:
1) Open the Rig Control documentation in the Wiki: https://wiki.hamradiodeluxe.com/index.php?title=Rig_Control#Synchronizer
2) Go to the "Synchronizer" section; at the time of this writing, it is section 5.3 in the TOC.

Bug#1) The odcumentation, without any descriptive explanation, includes the config file for the Serial Port Server service. Because there's no description or explanation of the file, it seems completely anacronistic. The Serial Port Server doens't have much (I believe) to do with the synchronizer feature.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2729 [2 - Next Dev List (Holding Area)] Bug minor always 2018-05-20 23:41 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: describes obsolete menu item, software
Description:
The documentation for Rig Control describes an obsolete menu choice and software. The documentation should be updated to reflect the actual state of the product in this area.
Tags:
Steps To Reproduce: 1) Visit this page: https://wiki.hamradiodeluxe.com/index.php?title=Rig_Control

2) Search for the heading "Ham Radio Deluxe Serial Port Client" on the page

BUG#1) Screen shots in this section are labelled "Version 5.0", which is pretty old. The command "Port Client" no longer exists in the indicated "Tools > Programs" menu tear-off.
Additional Information:
Attached Files:
Notes
(0005347)
WA9PIE   
2018-06-16 01:25   
One thing is for sure... these images shouldn't have version specific references in them.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2728 [2 - Next Dev List (Holding Area)] Bug minor always 2018-05-20 23:27 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: docs seem to confuse HRDSerialPortSvr with HRDRemoteSvr
Description:
The product ships two services: HRDRemoteSvr and HRDSerialPortSvr.

The documentation doesn't make their roles or usage clear. The same section of the documentation seems to describe both, interchangably showing screenshots with the two names. This should be clarified.
Tags:
Steps To Reproduce:
1) Go to this page: https://wiki.hamradiodeluxe.com/index.php?title=Rig_Control

2) Search on that page for this text string: "Ham Radio DeluxeRemoteSvr.exe "

BUG#1) This file, and the matching "Ham Radio DeluxeRemoteSvr.cfg" file aren't the correct names. The product actually uses HRDRemoteSvr.EXE and HRDRemoteSvr.CFG.

BUG#2) In this section of the document, one screen shot shows configuration for HRDRemoteSvr and another screen shot shows HRDSerialPortSvr.

BUG#3) In this section of the document, text for a config file is shown and the description given says it's for the Remote Server. The text in the config file is actually from the HRDSerialPortSvr.CFG file.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2676 [2 - Next Dev List (Holding Area)] Bug crash always 2018-04-14 10:23 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: new Product Version: 6.4.0.805  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: Logbook: Printing "Award Credits Matrix" causes a crash
Description: Looks like the logic to build the Award Credits Matrix is flawed; an array lookup is walking past the end of the array, which causes a crash.
Tags:
Steps To Reproduce: 1) Start up Logbook
2) Load the WA9PIE sample database
3) Open the Awards Window by clicking on "Awards Tracking" in the toolbar
4) Activate the "Award Tracking" tab
5) Click on "Print" in the toolbar
6) In the resulting "Print" dialog, make the options look like this:

[ ] Print Summary Report
[x] Print Award Credits Matrix
    [ ] Sort by column 2 (Full description)
    [x] Show Type Colors
[ ] Print Record Sheet from Template // disabled


7) Press OK to print

Retail builds will crash. Debug builds assert with an error about an array being overrun, with the attached callstack.

Additional Information:
> HRDLogbook.exe!CUIntArray::ElementAt(int nIndex=340) Line 170 C++
     HRDLogbook.exe!CUIntArray::operator[](int nIndex=340) Line 186 C++
     HRDLogbook.exe!CAwards2View::DrawCreditReport(CDC * pDC=0x041ce1d8, CRect & rect={...}, int nStart=291) Line 1863 C++
     HRDLogbook.exe!CAwards2View::PrintCreditReport(CDC * pDC=0x041ce1d8) Line 1612 C++
     HRDLogbook.exe!CAwards2View::OnFilePrint() Line 1289 C++
     HRDLogbook.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x2217b628, unsigned int nID=57607, int nCode=0, void (void) * pfn=0x0124f824, void * pExtra=0x00000000, unsigned int nSig=58, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 77 C++
     HRDLogbook.exe!CCmdTarget::OnCmdMsg(unsigned int nID=57607, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 373 C++
     HRDLogbook.exe!CView::OnCmdMsg(unsigned int nID=57607, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 164 C++
     HRDLogbook.exe!CFrameWnd::OnCmdMsg(unsigned int nID=57607, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 980 C++
     HRDLogbook.exe!CWnd::OnCommand(unsigned int wParam=57607, long lParam=0) Line 2784 C++
     HRDLogbook.exe!CFrameWnd::OnCommand(unsigned int wParam=57607, long lParam=0) Line 384 C++
     HRDLogbook.exe!CWnd::OnWndMsg(unsigned int message=273, unsigned int wParam=57607, long lParam=0, long * pResult=0x041cea04) Line 2108 C++
     HRDLogbook.exe!CXTPCommandBarsSiteBase<CMDIChildWnd>::OnWndMsg(unsigned int message=273, unsigned int wParam=57607, long lParam=0, long * pResult=0x041cea04) Line 191 C++
     HRDLogbook.exe!CWnd::WindowProc(unsigned int message=273, unsigned int wParam=57607, long lParam=0) Line 2094 C++
     HRDLogbook.exe!AfxCallWndProc(CWnd * pWnd=0x1bc10368, HWND__ * hWnd=0x00020c48, unsigned int nMsg=273, unsigned int wParam=57607, long lParam=0) Line 282 C++
     HRDLogbook.exe!AfxWndProc(HWND__ * hWnd=0x00020c48, unsigned int nMsg=273, unsigned int wParam=57607, long lParam=0) Line 435 C++
     user32.dll!__InternalCallWinProc@20() Unknown
     user32.dll!InternalCallWinProc() Unknown
     user32.dll!UserCallWinProcCheckWow(struct _ACTIVATION_CONTEXT *,void *,struct HWND__ *,enum _WM_VALUE,unsigned int,long,void *,int) Unknown
     user32.dll!CallWindowProcAorW(long (*)(struct HWND__ *,unsigned int,unsigned int,long),struct HWND__ *,enum _WM_VALUE,unsigned int,long,int) Unknown
     user32.dll!_CallWindowProcW@20() Unknown
     HRDLogbook.exe!CXTPHookManager::HookWndProc(HWND__ * hWnd=0x00020c48, unsigned int message=273, unsigned int wParam=57607, long lParam=0) Line 267 C++
     user32.dll!__InternalCallWinProc@20() Unknown
     user32.dll!InternalCallWinProc() Unknown
     user32.dll!UserCallWinProcCheckWow(struct _ACTIVATION_CONTEXT *,void *,struct HWND__ *,enum _WM_VALUE,unsigned int,long,void *,int) Unknown
     user32.dll!SendMessageWorker(struct tagWND *,unsigned int,unsigned int,long,int) Unknown
     user32.dll!SendMessageW() Unknown
     HRDLogbook.exe!CWnd::SendMessageW(unsigned int message=273, unsigned int wParam=57607, long lParam=0) Line 32 C++
     HRDLogbook.exe!NotifyExecute(CXTPControl * pControl=0x22195f90, CWnd * pOwner=0x1bc10368) Line 699 C++
     HRDLogbook.exe!CXTPControl::OnExecute() Line 912 C++
     HRDLogbook.exe!CXTPControl::ClickToolBarButton(CRect rcActiveRect={...}) Line 783 C++
     HRDLogbook.exe!CXTPControlButton::OnClick(int bKeyboard=0, CPoint pt={...}) Line 73 C++
     HRDLogbook.exe!CXTPControl::OnLButtonDown(CPoint point={...}) Line 1327 C++
     HRDLogbook.exe!CXTPCommandBar::OnLButtonDown(unsigned int nFlags=1, CPoint point={...}) Line 434 C++
     HRDLogbook.exe!CXTPToolBar::OnLButtonDown(unsigned int nFlags=1, CPoint point={...}) Line 1018 C++
     HRDLogbook.exe!CWnd::OnWndMsg(unsigned int message=513, unsigned int wParam=1, long lParam=1638431, long * pResult=0x041cf9e0) Line 2596 C++
     HRDLogbook.exe!CXTPCommandBar::OnWndMsg(unsigned int message=513, unsigned int wParam=1, long lParam=1638431, long * pResult=0x041cf9e0) Line 2416 C++
     HRDLogbook.exe!CWnd::WindowProc(unsigned int message=513, unsigned int wParam=1, long lParam=1638431) Line 2094 C++
     HRDLogbook.exe!AfxCallWndProc(CWnd * pWnd=0x1bd0a6a0, HWND__ * hWnd=0x00010c64, unsigned int nMsg=513, unsigned int wParam=1, long lParam=1638431) Line 282 C++
     HRDLogbook.exe!AfxWndProc(HWND__ * hWnd=0x00010c64, unsigned int nMsg=513, unsigned int wParam=1, long lParam=1638431) Line 435 C++
     user32.dll!__InternalCallWinProc@20() Unknown
     user32.dll!InternalCallWinProc() Unknown
     user32.dll!UserCallWinProcCheckWow(struct _ACTIVATION_CONTEXT *,void *,struct HWND__ *,enum _WM_VALUE,unsigned int,long,void *,int) Unknown
     user32.dll!_DispatchMessageWorker@8() Unknown
     user32.dll!_DispatchMessageW@4() Unknown
     HRDLogbook.exe!AfxInternalPumpMessage() Line 181 C++
     HRDLogbook.exe!CWinThread::PumpMessage() Line 900 C++
     HRDLogbook.exe!CWinThread::Run() Line 629 C++
     HRDLogbook.exe!CWinApp::Run() Line 787 C++
     HRDLogbook.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00850000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x066032c8, int nCmdShow=10) Line 47 C++
     HRDLogbook.exe!wWinMain(HINSTANCE__ * hInstance=0x00850000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x066032c8, int nCmdShow=10) Line 26 C++
     HRDLogbook.exe!__tmainCRTStartup() Line 251 C
     HRDLogbook.exe!wWinMainCRTStartup() Line 165 C
     kernel32.dll!@BaseThreadInitThunk@12() Unknown
     ntdll.dll!__RtlUserThreadStart() Unknown
     ntdll.dll!__RtlUserThreadStart@8() Unknown

    
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2665 [2 - Next Dev List (Holding Area)] Bug minor always 2018-04-08 13:17 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Documentation
Testing: Not Started
Summary: DM780: irrelevant help text in PSK Reporter Test window
Description:
There's some irrelevant help text in the PSK testing dialog box. We should remove the text altogether, or replace it with something useful to users.


Tags:
Steps To Reproduce:
1) Fire up DM780. Don't need a radio connection
2) Use the "Program Options" command in the "Tools" menu
3) In the resulting "Program options" dialog, click on "PSK Reporter"
4) In the resulting "PSK Propagation Reporter" window, There's a ton help text in the beige window at the top of the dialog.

That text starts out: "Use this window to configure automatic copying of received images to the web site of your choice using FTP", which is completely irrelevant to PSK reporter.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2641 [2 - Next Dev List (Holding Area)] Bug crash always 2018-03-30 11:23 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.797  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing: Not Started
Summary: DM780: debugging symbols not available for Olectra Chart DLL, used in Band Scope
Description: The olch2d32.dll file doesn't have debugging symbols as a result of our build process. Without symbols (a matching olch2d32.pdb file) crashes involving this code produce minidumps that can't be analyzed or debugged.

We need to make a build of this DLL, save the PDBs, and check them in so they're available with each release.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2638 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-03-29 20:19 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: "Network Server" configuration is not updated when a database configuration is deleted
Description:
The Logbook has a configuration which selects a default database for network operations, like the HRD CLI, or communications from other applications like DM780. It's possible for the user to delete the database configured as the default for Network SErver operations; the application doesn't notice this condition, silently fails calls, and causes trouble for users.
Tags:
Steps To Reproduce: 1) Open the Logbook. Make sure you have a spare database available.
2) Use the "Network Server" command in the "Configure" menu.
3) In the "Database" dropdown of the "Network server" dialog, select your spare database by name.
4) Press "OK" to exit the dialog.
5) Fire up DM780.
6) Use the ALE in DM780 to try to query or add a callsign to your log. Works fine.
7) Go back to the logbook. Right-click on the list of databases, which brings up the ODBC configurations for the logbook databases.
8) Select your spare, currently open database.
9) Press the "Delete" button.
10) In the resulting prompt, indicate that you do indeed want to delete the data source configuration.
11) Go back to DM780. Try again to manage a callsign with the ALE.

BUG#1) It doesn't work.

12) Back to the Logbook. Again use the "Network Server" command in the "Configure" menu.

BUG#2) Note that the spare database _isn't_ selected, but the Logbook is still trying to talk to it by default.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2637 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-03-29 20:19 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.797  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: Possible to delete the configuration for the currently open logbook
Description: If the user removes the conifguration for the currently open logbook database, the Logbook application doesn't notice. This results in unpredictable behaviour.

Tags:
Steps To Reproduce: 1) Open the Logbook. Make sure you have a spare database available.
2) Open that spare database.
3) Right-click on the list of databases, which brings up the ODBC configurations for the logbook databases.
4) Select your spare, currently open database.
5) Press the "Delete" button.
6) In the resulting prompt, indicate that you do indeed want to delete the data source configuration.
7) Press OK.

BUG#1) The database is deleted, but the logbook still (tries to) behave as if the database is opened.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2617 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-03-24 09:38 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.797  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: PSK Reporter
Testing: Not Started
Summary: Digital Master: late-binds to PSDKReporter SDK DLL
Description: The code in Digital Master which uses PSKReporter explicitly links to the PSKReporter SDK DLL. That is, it uses LoadLibrary() get the library, then GetProcAddress() to pick off each function it wants to call. There's no reason for this; HRD should install the PSKReoprter.DLL file (it already does) and use it with implicit linking. All the code to manually load the library and get the address of each function can be removed.

The code to load the library explicitly is copied-and-pasted in two places. One is CBackgroundProcessingThread::PskPropagationReport(), and the other is CPskPropRepOptions::OnTest().

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2608 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-03-18 17:16 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.4.0.794  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Logbook Filter: populate selection pulldown for choosable fields
Description:
Some columns in the Logbook database have known, finite lists of valid values. When such a column is selected, the logbook filter UI could populate those values for the user.

Tags:
Steps To Reproduce: 1) Fire up the Logbook application
2) Open your favorite database
3) Press the "Filter" button on the toolbar to show the Filter UI
4) Mark the first "Field" checkbox
5) In the dropdown, select "QSL received"
6) Select "Equals"
7) Note the "Value" field is blank.
Additional Information:
Attached Files:
Notes
(0004511)
K7ZCZ   
2018-03-18 17:33   
I've related this to bug 2236, which first suggested the cleanup of the "Y/N" filters.

The challenge is that, while we think there should be a limited set of values in certain fields, there are not: very little validation is done on data in the logbook database. Values in the "Sent" or "Received" fields, for example, might be "Y", "Yes", "N", "No", or blank (NULL). Presenting the user with a dropdown with five choices would be pretty confusing.

Maybe we can work something out where selecting "Y" and "N" is possible, then the program searches for ("Yes" OR "Y"), for example.

Or, maybe we need to initiate a complete overhaul of the logbook, get the data cleaned-up nice, and then we can have nicer things in many different areas.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2606 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-03-18 17:10 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.4.0.794  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Logbook filter: validate values from known lists where possible
Description: The logbook filter could validate values for input from known lists.

For example, there are there are only 40 CQ zones - but any integer might be entered in the field, even if not valid.

Tags:
Steps To Reproduce: 1) Fire up the Logbook application
2) Open your favorite database
3) Press the "Filter" button on the toolbar to show the Filter UI
4) Mark the first "Field" checkbox
5) In the dropdown, select "DXCC"
6) Sleect "Equals" for "Match"
7) Enter "99999" for the value.

There's no such country code. Maybe too many to list in a drop down, but it would be nice to validate among the valid values before a search starts.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2605 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-03-18 17:08 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: k6mkf OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 6.4.0.794  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Functional
Testing: Not Started
Summary: Logbook filter: provide a "distinct" button
Description:
A use has suggested that we Add ‘Distinct’ feature to the filter fields: e.g. how many (distinct) entities have I worked on FT8?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0004510)
K7ZCZ   
2018-03-18 17:26   
This needs further information. To me, a DISTINCT slection would mean that we just list the mode, FT8. Finding a count would be performing an aggregation on another column: for each distinct mode, tell me how many contacts have been made. That would quickly suggest the need for further aggregations: for each mode, how many contacts made? How many ackwnowledged on LOTW? how many ackwnoledge on QRZ? Of those, how many per band?

The filter is for finding values, not building reports. So, maybe there's a different feature you're requesting.

Can you color in what problem it is you'd like to solve? Then, maybe I can figure a feasible solution for you.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2599 [2 - Next Dev List (Holding Area)] Maintenance minor always 2018-03-11 13:28 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: N/A
Summary: ShellExecute wrapper functions copy-and-paste cleanup
Description:
There are five versions of the OwnShellExecute module floating around. This code is just wrapper over some ::ShellExecuteEx() calls for various goals. The various versions are enumeated below.

This code should be refactored:

1) Move to HRDCommon library so there's just one copy
2) Fix/repair calling sites to reference that single copy
3) Encapsulate global declarations into class with static members for namespace scoping.


Tags:
Steps To Reproduce:
Additional Information:
C:\HRDNew>dir ownshellexecute.cpp ownshellexecute.h /s
 Volume in drive C has no label.
 Volume Serial Number is 085F-63D6

 Directory of C:\HRDNew\Digital Master\Digital Master

2018-03-02  07:52             4,334 OwnShellExecute.cpp

 Directory of C:\HRDNew\Digital Master\Digital Master

2018-03-02  07:52               299 OwnShellExecute.h
               2 File(s)          4,633 bytes

 Directory of C:\HRDNew\HamRadioDeluxe

2018-03-02  07:54             5,269 OwnShellExecute.cpp

 Directory of C:\HRDNew\HamRadioDeluxe

2018-03-02  07:54               250 OwnShellExecute.h
               2 File(s)          5,519 bytes

 Directory of C:\HRDNew\Logbook\HRDLogbook

2018-03-02  07:55             4,334 OwnShellExecute.cpp

 Directory of C:\HRDNew\Logbook\HRDLogbook

2018-03-02  07:55               299 OwnShellExecute.h
               2 File(s)          4,633 bytes

 Directory of C:\HRDNew\Rotator

2018-03-02  07:56             4,252 OwnShellExecute.cpp

 Directory of C:\HRDNew\Rotator

2018-03-02  07:56               299 OwnShellExecute.h
               2 File(s)          4,551 bytes

 Directory of C:\HRDNew\Satellites\SatTrack

2018-03-02  07:56             4,906 OwnShellExecute.cpp

 Directory of C:\HRDNew\Satellites\SatTrack

2018-03-02  07:56               359 OwnShellExecute.h
               2 File(s)          5,265 bytes

     Total Files Listed:
              10 File(s)         24,601 bytes
               0 Dir(s)  299,074,973,696 bytes free
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2598 [2 - Next Dev List (Holding Area)] Bug minor always 2018-03-10 15:52 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 1703  
Status: new Product Version: 6.4.0.794  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Documentation
Testing: Not Started
Summary: documentation: out-dated screen shot and description of "import" feature in logbook
Description: The screenshot in the documentation which explains importing log files is out-dated.

The text says there are five options shown, and the screen-shot shows that. But in the actual product, only four options are available. The product doesn't have an "ADIF 3 (ADX)" option.

Tags:
Steps To Reproduce:
Additional Information:

The screen shot in question is in this topic:
https://wiki.ham-radio-deluxe.com/index.php/Logbook#Importing_Log_Files
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2583 [2 - Next Dev List (Holding Area)] Maintenance minor always 2018-03-08 14:17 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: K7ZCZ OS: Windows 10 Professional x64  
Priority: normal OS Version: 1703  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: General
Testing: Not Started
Summary: upgrade to new version of CxImage
Description: We use a library called CxImage to process images, most notably in the Rotator and Mapper applications.

The version of the library we're using is quite old; 5.99 from 2004. The currently available version is 7.0.1.0 from 2011.

We should upgrade this library to pick up newer code, get bug fixes, and so on.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0004451)
K7ZCZ   
2018-03-08 14:18   
https://sourceforge.net/projects/cximage/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2259 [2 - Next Dev List (Holding Area)] Bug minor always 2017-09-21 10:07 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 1703  
Status: new Product Version: 6.4.0.787  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Rig Control: several menu items have duplicate, incorrect tool tip
Description:
The same tool tip is incorrectly re-used in three or four menu items in Rig Control.
Tags:
Steps To Reproduce:
1) Fire up Rig Control. Demo radio is fine.
2) Click on the "View" menu.
3) Hover over the "Edit", "Main", "Program", and "Various" commands in this menu until a tool tip appears.

BUG#1) Note that the tool tip is the same for each menu item, even when it doesn't match the menu item.
Additional Information: I've dug into this a bit, and there's some sort of CodeJock thing going on as these menu choices are dynamically added, and appear to get a default tool tip. It wasn't evident after some cursory searching about how to set specific tool tip text for the dynamically added commands.

System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2258 [2 - Next Dev List (Holding Area)] Maintenance minor always 2017-09-21 09:47 2020-07-02 02:13
Reporter: K7ZCZ Platform:  
Assigned To: K7ZCZ OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 6.4.0.787  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: (select)
Testing: Not Started
Summary: Cleanup: deduplicate, refactor CSettings class
Description:
CSettings manages persistent settings. The class is specialized to the options of each application for the settings that application wants to handle, but thjere's lots of boiler-plate code which has been copied and deviated over time. A sensible approach would factor the common code out and leave a base class, which each application could derive from to implement their specific settings. Some applications have partial implementations of such a class, but they don't share that, either.

As always, consolidating code eases maintenance by letting us fix bugs and make enhancements only once.
Tags:
Steps To Reproduce:
These applications have a CSettings implementation:

DM780
Ham Radio Deluxe (Rig Control)
Rotator
Mapper
Logbook
Satellite Tracker

These applications have a CSettingsBase class implementation:

DM780
Ham Radio Deluxe (Rig Control)
Logbook
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2109 [2 - Next Dev List (Holding Area)] Bug crash always 2017-07-07 13:50 2020-07-02 02:13
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 1703  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing:
Summary: Canada.Country lookup is too large to load in memory
Description:
Data in the Canada.Country module is stored as an XML resource. The resource is about 125 megs in its ASCII representation. It must be converted to Unicdoe to be fed to the XML parser, then shredded into an in-memory data structure.

The Unicode representation would be approximately 250 megs. The in-memory representation is probably 25% of that size, but the Unicode representational remains in memory intil it is completely digested -- the peak memory usage is about 250 * (1 + 0.25) == 312 megs, then. This should fit in a 32-bit process, but is substantial ... and since the XML data is monolithic, it is hard to manage.

A good solution would be to not use XML; then also not use the XML parser. Combined, that means the resource will be substantially smaller and won't need to be converted to Unicode monolithically. The smaller representation can be kept as a static resource where it won't cause a memory allocation, and the data structure built from that representation.
Tags:
Steps To Reproduce:
1) Manually build the Canada.Country DLL
2) Make sure it's next to the HRDLogbook.EXE (same directory)
3) Run HRDLogbook.EXE
4) Place a break point on the parser thread function; it's called "LoadCitiesProc"
5) Connect to a cluster.
6) When the break point is hit, you can step through the code to find the code loads the resource, and fails to convert it to Unicode because memory can't be allocated for the conversion (a 250-meg request). The code tries to recover from this error by allocating a CStringW that holds about 125 milllion characters -- another 250-meg memory allocation request. That fails with an unhanded exception from CString and the app crashes.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3131 [2 - Next Dev List (Holding Area)] Bug minor sometimes 2019-01-28 11:05 2020-07-02 02:12
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Satellite Tracker can hang when redrawing world map pane
Description:
The Satellite Tracker app can end up hanging when trying to refresh the world map pane.


Tags:
Steps To Reproduce:

1) Start up Satellite Tracker
2) On the "Satellite Definitions" tab, use the "Enable all" toolbar button to mark all satellites
3) Use the "Next Passes" button on the main toolbar
4) In the resulting "Passes:1KUNS-PF" tab, mark the "World Map" toolbar button to display the world map tracking view
5) In the "Passes" tool bar, mark the "Only" radio button
6) Repeatedly select different satellites from the dropdown in the "Passes" tool bar, next to the "Only" radio button
Additional Information:
System Description
Attached Files:
Notes
(0007102)
K7ZCZ   
2019-01-28 12:32   
I had a call stack here, but Mantis didn't save it.

The issue is that CPaneNextPasses::GetNextPassesEx() iterates over an array of satellites. It caches the size of that array, then works through the array, sometimes removing elements from the array as it goes. The loop uses the cached size of the array in its invariant rather than re-evaluating the size of the array.
(0007103)
K7ZCZ   
2019-01-28 12:37   
Turns on the bad code (the cached loop invariant) is copied to another function -- which might even be the original function, lost in the Mantis reset. In reproducing the problem, I find this call stack, where CPassesView::GetNextPassesEx() is (mostly) copy-and-paste from CPaneNextPasses::GetNextPassesEx().


>	HRDSatTrack.exe!CPassesView::GetNextPassesEx(CUIntArray & anAllAOS, CUIntArray & anAllLOS, CStringArray & astrAllName) Line 1640	C++
     HRDSatTrack.exe!CPassesView::OnRefresh() Line 719	C++
     HRDSatTrack.exe!CPassesView::Refresh() Line 668	C++
     HRDSatTrack.exe!CPassesFrame::OnSatellite(tagNMHDR * pNMHDR, long * pResult) Line 463	C++
     HRDSatTrack.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void(CCmdTarget::*)() pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 106	C++
     HRDSatTrack.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 372	C++
     HRDSatTrack.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 984	C++
     HRDSatTrack.exe!CXTPControl::NotifySite(CWnd * pSite, unsigned int code, NMXTPCONTROL * pNM) Line 497	C++
     HRDSatTrack.exe!NotifyExecute(CXTPControl * pControl, CWnd * pOwner) Line 333	C++
     HRDSatTrack.exe!CXTPControl::OnExecute() Line 575	C++
     HRDSatTrack.exe!CXTPControlComboBox::OnExecute() Line 850	C++
     HRDSatTrack.exe!CXTPControlComboBoxList::OnLButtonUp(unsigned int __formal, CPoint __formal) Line 196	C++
     HRDSatTrack.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2612	C++
     HRDSatTrack.exe!CXTPCommandBar::OnWndMsg(unsigned int message, unsigned int wParam, long lParam, long * pResult) Line 2621	C++
     HRDSatTrack.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2099	C++
     HRDSatTrack.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 265	C++
     HRDSatTrack.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 418	C++
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!DispatchMessageWorker()	Unknown
     user32.dll!_DispatchMessageW@4()	Unknown
     HRDSatTrack.exe!AfxInternalPumpMessage() Line 181	C++
     HRDSatTrack.exe!CWinThread::PumpMessage() Line 900	C++
     HRDSatTrack.exe!CWinThread::Run() Line 629	C++
     HRDSatTrack.exe!CWinApp::Run() Line 787	C++
     HRDSatTrack.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47	C++
     HRDSatTrack.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26	C++
     HRDSatTrack.exe!invoke_main() Line 123	C++
     HRDSatTrack.exe!__scrt_common_main_seh() Line 288	C++
     HRDSatTrack.exe!__scrt_common_main() Line 331	C++
     HRDSatTrack.exe!wWinMainCRTStartup() Line 17	C++
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown
(0007104)
K7ZCZ   
2019-01-28 13:05   
Even with the speculative fix of not caching the array length, the issue persists. In CPassesView::GetNextPassesEx(), the arrSatellites array isn't adjusted during the loop, so this is no surprise.

For me, the issue is reproducable readily using a specific specific satellite. Perhaps it has to do with my QTH, which is at CN87. Here are the steps I'm using:

1) Start up Satellite Tracker
2) On the "Satellite Definitions" tab, use the "Enable all" toolbar button to mark all satellites
3) Use the "Next Passes" button on the main toolbar
4) In the resulting "Passes:1KUNS-PF" tab, mark the "World Map" toolbar button to display the world map tracking view
5) In the "Passes" tool bar, mark the "Only" radio button
6) select the "ChubuSat-2" satellite


After that selection, the application hangs, stuck in the GetNextPassesEx() loop. I'll hvae to dig into it more to figure out why the app hangs for certain satellites and not others.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3122 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-27 11:21 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control has two different sliders numbered "132" for FT-891
Description:
Two sliders in the available list for the Yaesu FT-891 are both numbered "132". Depending on what we decide when writing our style guide (see Mantis 3063), we should fix these labels.


Tags: FT-891, Yaesu
Steps To Reproduce: 1) Get Rig Control started and connect to an FT-891
2) Use the "View" command to find the "Customize" tear-off. In that menu, use the "Customize Layout" command
3) In the resulting "Customize Layout" dialog, activate the "Sliders: Layout" tab
4) Search through the list in any dropdown.

BUG#1) The dropdown will contain both "132 Proc EQ2 Level" and "132 Proc EQ1 Bandwidth". Depending on the outcome of Mantis 3063, these labels should be fixed to either have not have numbers at all, or use the correct section-item numbers that match the radio.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3121 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-01-27 11:20 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control doesn't support display dimmer, contrast settings; keyboard dimmer settings for FT-891
Description:
Many radios have dimmer settings for their displays which are controllable through their CAT or CI-V interfaces. The FT-891 has such settings, but Rig Control doesn't implement sliders for them.

When working our Rig Control Style guide out (see Mantis 3063) we should consider if these settings should be implemented for all radios, or just some.
Tags: FT-891, Yaesu
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3114 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-26 19:41 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: FT-891 sliders aren't numbered consistently
Description: There's some concern that sliders for Yaesu radios should; be numbered with the same menu number that the radio uses in order to make them easy to find. If we decide to do this, we should do it uniformly. See Mantis 3063 for the issue tracking naming conventions in Rig Control.

When 0003063 is resolved, then we should consider fixing the Rig Control sliders for the FT-891. The radio uses a four-digit numbering scheme for its settings, where the menus are broken into groups. "05-03", for example, identifies the third menu in the fifth group. That setting happens to be "NB LEVEL", but the corresponding Rig Control slider uses the name "025 NB Level".

All of the sliders for the FT-891 are numbered with three digits rather than the page-number groupings that the radio actually uses.

Tags: FT-891, Yaesu
Steps To Reproduce:
1) Start Rig Control. Connect to the FT-891.
2) Hold the "F" button to display the individual settings menu
3) Find setting "05-03"; it's "NB LEVEL"
4) Find the corresponding slider in the rig control's layout customization dialog

BUG#1) it is labeled "025 NB Level". Should be "NB Level" if we don't use menu nubmers, or "05-03 NB Level" if we do use menu numbers. Or, maybe 3063 recommends something else entirely.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3112 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-26 17:51 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: FT-891 IF shift range isn't correct; can't be controlled from Rig Control
Description:
Rig Control's emulation of the FT-891 IF-shift setting doesn't have a correct range. The radio's setting moves from -1200 hertz to +1200 hertz. Rig Control only shows +/- 1000 hertz.

Rig Control can't be used to set the IF shift frequency.
Tags: FT-891, Yaesu
Steps To Reproduce:
1) Fire up Rig Control
2) Make sure the "IF shift" slider is visible
3) tap the "F" button on the radio to enter the function menu
4) repeatedly press "F" to find the "function-1" menu
5) Use the Multi knob to select the "SFT" choice
6) Press the Multi knob to activate the "SFT" choice
7) Rotate the multi knob left until the radio shows "-1200Hz"

BUG#1) Rig control shows only -1000 Hz.

8) Rotate the multi knob right until the radio shows "+1200Hz"

BUG#2) Rig control shows only +1000 Hz.


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3104 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-01-26 11:34 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Provide a way to configure keyboard shortcuts for buttons in Rig Control
Description: I think that Rig Control would benefit from the a feature that allowed the user to bind a keystroke combination to a button. Common actions would be settable to the user by their favorite key, and the keypress would activate any button they have configured. The W, A, S, and D buttons, for example, form an arrow on the keyboard. A user might configure A to tune down, D to tune up, S to go down a band, an W to go up. Of course, that's just an example: any setting might be possible CTRL+2 might send the second recorded CW message. CTRL+SHIFT+P might toggle the pre-amp. Since the user can configure whatever they'd like, they can set up their own preferences.

The feature could be implemented by adding a tab to the existing "Customize Layout" window in Rig Control. a Windows Hot Key Control (see https://docs.microsoft.com/en-us/windows/desktop/controls/create-a-hot-key-control ) could be used to accept the key bindings. We'd need logic to store and load the preferences, plus a good UI to show them to the user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3103 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-26 07:05 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Documentation
Testing: Not Started
Summary: documentation for Satellite Tracker is out of date
Description: The documentation for Satellite Tracker doesn't seem like it is at all current. It mentions files that don't exist, shows screen shots that don't match, and would probably leave any user bewildered and lost.
Tags:
Steps To Reproduce: 1) Start Satellite Tracker
2) Use your borwser to visit https://wiki.hamradiodeluxe.com/index.php?title=Satellite_Tracking

BUG#1) The screen shots in the documentation don't match the product at all
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3100 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-26 06:49 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: Help link for ISS in Satellite Tracker is 404
Description: The Satellite Tracker app provides an incorrect link to information about the ISS.
Tags:
Steps To Reproduce: 1) Start up Satellite Tracker
2) In the "Satellite Definitions" tab, use the "Enable All" button to enable all satellites
3) In the main window's toolbar, use the drop-down arrow next to the "Help" button
4) The resulting menu has an "ISS" tear-off. Click the "AMSAT" command in that menu

BUG#1) Goes to a 404 landing page. The address I see is here, but maybe it's a redirect? https://www.amsat.org/amsat-new/satellites/satInfo.php?satID=19&retURL=/satellites/status.php

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3098 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-25 11:49 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Satellite Tracker logfile view scrolls inappropriately
Description: The Satellite Tracker's logfile view goes crazy with a mouse click. No sane application works this way.
Tags:
Steps To Reproduce:
1) Start up Satellite Tracker
2) Use the "View" menu to find the "Logfile" command
3) Scroll upwards to see older items
4) Click anywhere in the window and drag as if you're highlighting something

BUG#1) The content suddenly scrolls all the way to the top. Your mouse has moved way past your control -- probably to the top right of your desktop. It might not even be on the same monitor!
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3084 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-21 11:30 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control doesn't support default "SSB" mode for Yaesu FT-891
Description:
Some radios require more than one command to change modes, or show a different user interface than most radios when selecting modes. The FT-891 is one such example, which does both. It shows "SSB" mode as a selectable choice for the user, but discerns between "USB" and "LSB" in the display of the setting.

Rig Control doesn't support sending multiple commands to set (or read) a mode from its controls or programmatic interface, so it doesn't work too well with the FT-891. Rig Control also doesn't have good support for "SSB" mode, as it expects the radio and the user to explicitly discern between "USB" and "LSB".

We should decide how to address this issue carefully. While the radio's behaviour might seem odd and certainly is incongruent with the way that Rig Control is designed, forcing the radio to behave a certain way might actually be unexpected to users who are very familiar with the radio and expect this behaviour.

Tags: FT-891, Yaesu
Steps To Reproduce:
Additional Information:
The Yaesu FT-891 is a compact, mobile HF tranceiver. To accommodate for the small size of the radio's display and front panel, Yaesu makes some design concessions for the way the radio works and is used. One such design choice influences the way the radio interacts with Rig Control.

That concession is this: the radio supports an "SSB" mode, which doesn't always explicitly differentiate between LSB and USB modes. The radio's mode setting allows only "SSB", and doesn't give the user explicit choice over USB or LSB.

This mode setting mechanism is described on page 29 of the regular (not advanced) manual:

1) Press and hold the "BAND" button on the radio.
2) After about a second, a mode setting display appears.
3) The VFO knob is used to select a mode. "SSB" is the only selectable mode; specific "USB" and "SSB" settings are not offered.

The radio does, however, display "USB" or "LSB" on the default tuning/VFO screen. The radio will automatically choose LSB or USB depending on the frequency band selected, and that setting is displayed there. The user can explicitly select a sideband with menu choice 11-07, called "SSB BFO". The choices for this setting are USB, LSB, or AUTO. Setting USB on 40 meters, counter to the default of LSB, means following these steps:

1) Press the "BAND" button
2) Use the VFO to select 40 meters
3) Wait for the radio to return to the VFO screen
4) Press and hold the "BAND" button
5) After about a second, the mode screen is shown.
6) Use the VFO knob to select "SSB".
7) Wait for the radio to return to the VFO screen
8) Press and hold the "F" button
9) In the menu list, select item "11-07" with the multi knob.
10) Press the multi-knob in.
11) Use the multi-knob to select "USB"
12) Press the "F" button to exit the setting

The radio returns to the VFO screen, showing a frequency in 40 meters and "USB" mode.

This seems pretty cumbersome, but it's the way the radio works from the touch screen. From the CAT interface, things are a bit different:

The "MA" command is used to set mode. "MD01" sets LSB and "MD02" sets USB. "MD0" retrieves the operating mode. "MD01" will set LSB regardless of the SSB BFO setting, and "MD0" will confirm that setting. However, if the radio was previously set USB, the VFO screen on the radio will not reflect the LSB setting and remain at USB. To users of Rig Control, this appears as a mismatch between the setting that Rig Control has made (and received back) from the radio, and what the radio actually displays.

The "IF" command can be sent to retrieve several operating parameters, including frequency, memory/VFO mode, clarifier settings, and so on. The radio's response to this command also includes the transmit mode, and that transmit mode follows the response given from "MD0" as above. That is, the "IF" command may also displays the CAT-selected mode even if the radio's front panel display shows a different mode.

It seems that the only way to explicitly set USB or LSB is to use both the MD command and a command to set the SSB BFO. To set USB mode, for example, we'd send "MD02" for USB, then "EX11070" to set the SSB BFO to "USB", as well.

Reading the mode similarly requires querying both the 11-07 menu setting and the value returned from the MD0 or IF commands.

The "auto" side band setting for SSB is also used for other modes. CW as the CW BFO setting at 07-07, the DATA mode has the DATA BFO setting at menu 08-12, and the RTTY mode has the RTTY BFO setting at menu 10-11. These all behave similarly, with the MD setting not following the displayed setting at the radio. The DATA and RTTY modes don't have "AUTO" BFO settings, and have only USB and SSB.

Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3078 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-19 13:04 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.184  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: (select)
Testing: Not Started
Summary: The "3rd-party Serial Port" dialog in Rig Control has an unused drop-down for CI-V addresses
Description:
The "3rd-party Serial Port" dialog in Rig Control has a drop-down for CI-V addresses.

This drop-down is initially populated with the address "0x00", which is not a valid CI-V address. Once selected in the dropdown, the value cannot be unselected. But the value doesn't appear to be used by anything, ever.

If this setting isn't useful, it should be removed. If it's meant to be hooked up to something, we need to figureout what it's meant to do and make it work.
Tags:
Steps To Reproduce:

1) Fire up Rig control. Don't connect to a radio
2) In the "Tools" menu, use the "Hardware" tear-off to click on the "3rd-Party Serial Support" command
3) Use the "CI-V Addr" drop-down to select "0x00".

BUG#1) Can't reset it to blank.

BUG#2) By static analysis of the code, nothing ever reads or uses this setting.

BUG#3) The documentation doesn't mention the setting -- the docs doen't even mention support for the CI-V protocol in this feature.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3068 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-17 10:22 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.183  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Documentation
Testing: Not Started
Summary: documentation should be revised to reflect changes to Callsign Lookup configuration
Description:
The callsign lookup settings dialogs have significantly changed in the 6.5 release. The documentation should be updated to reflect these changes.
Tags:
Steps To Reproduce: 1) start up the Logbook
2) Use the "Tools" menu to get the "Configuration" tear-off
3) Use the "Callsign Lookup" command in the "Configuration" tear off

4) Access the Logbook docs here: https://wiki.hamradiodeluxe.com/index.php?title=Logbook#Callsign_Lookups

BUG#1) the documentation doesn't match the application's UI


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3041 [2 - Next Dev List (Holding Area)] Maintenance minor have not tried 2019-01-06 15:29 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.166  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing: Not Started
Summary: Remove HRDLog001 project from the build
Description: The product has no run-time dependency on HRDLog001.DLL. However, it does have a build-time dependency on this project. An initial investigation suggests that the dependency is vestigial. It'll be a bit of work to analyze it and remove it, but removing it frees a bunch of false dependencies and lets us delete thousands of lines (and dozens of files) of unused code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3034 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-01-04 14:17 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Implement memory management feature for Kenwood radios in Rig Control
Description: Most Kenwood radios provide some setting memory features. The radio can store a mode, a frequency, some squelch settings, and some squelch or CTCSS tones in am memory which can be quickly accessed by number and/or name.

Rig Control could support reading, editing, and saving these memories, which would be an improvement over using the radio's front panel to enter and make the settings. Eventually, Rig Control could be made to tune or scan over selected (or all) memory stations.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3033 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-01-04 14:12 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Implement memory management feature for Yaesu radios in Rig Control
Description: Most Yaesu radios provide some setting memory features. The radio can store a mode, a frequency, some squelch settings, and some squelch or CTCSS tones in am memory which can be quickly accessed by number and/or name.

Rig Control could support reading, editing, and saving these memories, which would be an improvement over using the radio's front panel to enter and make the settings. Eventually, Rig Control could be made to tune or scan over selected (or all) memory stations.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3032 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-01-04 14:11 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Implement memory management feature for Icom radios in Rig Control
Description:
Most Icom radios provide some setting memory features. The radio can store a mode, a frequency, some squelch settings, and some squelch or CTCSS tones in a memory which can be quickly accessed by number and/or name.

Rig Control could support reading, editing, and saving these memories, which would be an improvement over using the radio's front panel to enter and make the settings. Eventually, Rig Control could be made to tune or scan over selected (or all) memory stations.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3030 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-03 14:23 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: remote server documentation, config file mention HB9DRV, are outdated and inaccurate
Description: Setup installs into the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\" directory these files:

HRDRemoteSvr.cfg
HRDRemoteSvr.rtf
HRDRemoteSvr_Sample.cfg


These files all mention HB9DRV. The content of the files is inaccurate and out-dated. Some of the files are not necessary. We should figure out if the files are needed or not; if used, then they should be cleaned up. If not used, they should be removed from the product.

Tags:
Steps To Reproduce: 1) install HRD
2) Go to the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory
3) examine the named files
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3027 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-03 14:12 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.164  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: Documentation
Testing: Not Started
Summary: "Country Data" documentation is outdated, mentions HB9DRV
Description: This file:

HRD Logbook - Country Data.pdf


is installed by the product into the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory.

It's not clear that this file is needed. If not required, it should be removed from the product. If required, is should be cleaned up and updated.
Tags:
Steps To Reproduce: 1) install HRD
2) Go to the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory
3) examine the named files; you'll need a PDF reader
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3026 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-03 14:09 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.164  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: "Macro Definition" files mention HB9DRV
Description: These files:

DMMacroDefns.xml
HB9DRV's PSK31 Deluxe Macros.txt
DMMacroDefns_001.xml
PSK31 Deluxe Macros v2.txt
PSK31 Deluxe Macros.txt


are installed by the product into the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory.

It's not clear that these files are needed. If they are not required, they should be removed from the product. If required, they should be cleaned up.
Tags:
Steps To Reproduce: 1) install HRD
2) Go to the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory
3) examine the named files; they have a header something like this:

############################################################
#
#   Ham Radio Deluxe by Simon Brown, HB9DRV
#
#   Contents ..: Configuration Options
#   Created ...: 04/11/04 13:57:58
#
#   The contents of this file must not be changed if the
#   program is to operate correctly. To avoid problems,
#   please do NOT edit this file.
#
############################################################


or like this:

<!--                                                           -->
<!-- ===================== WARNING ==========================  -->
<!-- | The contents of this file must not be changed if the |  -->
<!-- | program is to operate correctly. To avoid problems,  |  -->
<!-- | please do NOT edit this file.                        |  -->
<!-- ========================================================  -->
<!--                                                           -->
<!-- Filename ..: DMAlarmDefns.xml                             -->
<!-- Created ...: 02/12/2007 11:44:21                          -->
<!-- Computer ..: DOUBLETROUBLE                                -->
<!-- Username ..: Simon                                        -->
<!-- Program ...: Digital Master.exe                           -->
<!--                                                           -->
<!-- D:\Ham Radio\Digital Master\AlarmDefinitions.cpp line 317 -->
<!--                                                           -->

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3025 [2 - Next Dev List (Holding Area)] Bug minor always 2019-01-03 14:08 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.164  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: "Alarm Definition" files mention HB9DRV
Description: These files:

DMAlarmDefns.xml
HB9DRV's PSK31 Deluxe Alarms.txt
PSK31 Deluxe Alarms.txt


are installed by the product into the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory.

It's not clear that these files are needed. If they are not required, they should be removed from the product. If required, they should be cleaned up.

Tags:
Steps To Reproduce: 1) install HRD
2) Go to the "C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe" directory
3) examine the named files; they have a header something like this:

############################################################
#
#   Ham Radio Deluxe by Simon Brown, HB9DRV
#
#   Contents ..: Configuration Options
#   Created ...: 04/11/04 13:57:58
#
#   The contents of this file must not be changed if the
#   program is to operate correctly. To avoid problems,
#   please do NOT edit this file.
#
############################################################


or like this:

<!--                                                           -->
<!-- ===================== WARNING ==========================  -->
<!-- | The contents of this file must not be changed if the |  -->
<!-- | program is to operate correctly. To avoid problems,  |  -->
<!-- | please do NOT edit this file.                        |  -->
<!-- ========================================================  -->
<!--                                                           -->
<!-- Filename ..: DMAlarmDefns.xml                             -->
<!-- Created ...: 02/12/2007 11:44:21                          -->
<!-- Computer ..: DOUBLETROUBLE                                -->
<!-- Username ..: Simon                                        -->
<!-- Program ...: Digital Master.exe                           -->
<!--                                                           -->
<!-- D:\Ham Radio\Digital Master\AlarmDefinitions.cpp line 317 -->
<!--                                                           -->


Additional Information:
Attached Files:
Notes
(0007023)
PD9FER   
2019-01-17 16:44   
Checked the file DMAlarmDefns.xml in our installation folder.
It does not get Read from or written to.. save to remove
However in Roaming\HRDLLC\Digital Master\780 there is also a DMAlarmDefns.xml and possibly DMAlarmDefns01.xml (counting up) These are being used.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3023 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-03 14:02 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: example DDE spreadsheet uses old product versions, mentions HB9DRV
Description:
The DDE.XLS spreadsheet that ships with the product to demonstrate the DDE feature contains old HRD version numbers, links to an outdated non-company website, and mentions HB9DRV.

The DDE feature should be removed. If it is removed prompty, this file should be deleted. If file needs to stay, this file should be cleaned up and updated. (And updated to a modern Excel format, too.)
Tags:
Steps To Reproduce: 1) install HRD
2) C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe
3) Open and examine the DDE.xls file
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3022 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-01-03 13:59 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: (select)
Testing: Not Started
Summary: Most files in "%UserProfile%\AppData\Roaming\HRDLLC\Ham Radio Deluxe" directory mention HB9DRV
Description:
Most of the files in the "%UserProfile%\AppData\Roaming\HRDLLC\Ham Radio Deluxe" directory mention HB9DRV and have ancient (and ambiguous) dates. These files are at issue. Note that there's no clear information about these files: we don't know if they're used or not. If unused, they should be deleted. If used, they should be cleaned up.

AK9G.opt
Army Surplus.opt
Danielle's Amberglow.opt
Danielle's Blues.opt
Danielle's Borgcube.opt
Danielle's K2.opt
Danielle's Liquorice.opt
Danielle's Redeye.opt
Danielle's ts-2000.opt
Danielle's ts-480.opt
Danielle's Ultraviolet.opt
Dark.opt
Default.opt
Ginger.opt
Grey Scale.OPT
Greyfriars.OPT
HRD Countries.txt
HRD Favourites 01.txt
HRD Favourites 01.txt.xml
HRD Parallel Port Defns.txt
HRD Satellite Favourites.txt
HRDConnectSettings.xml
Igor'th Thpethial.opt
LCD.opt
Light.OPT
Matt, N8QQF.opt
N8PVZ's HRD Colour Scheme.opt
Night Vision.OPT
Nowt.opt
Oranges and Lemons.opt
PD5DP Blues.opt
Peter's Persuasion.opt
PG5S Icom.OPT
Plastic Blue.opt
Plastic Green.opt
Plastic Kahki.opt
Plastic Orange.opt
radionow.htm
Traditional.opt


Tags:
Steps To Reproduce: 1) install HRD
2) Go to the "%UserProfile%\AppData\Roaming\HRDLLC\Ham Radio Deluxe" directory
3) examine the named files; they have a header something like this:

############################################################
#
#   Ham Radio Deluxe by Simon Brown, HB9DRV
#
#   Contents ..: Configuration Options
#   Created ...: 07/19/03 13:27:16
#
#   The contents of this file must not be changed if the
#   program is to operate correctly. To avoid problems,
#   please do NOT edit this file.
#
############################################################

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2987 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-12-13 12:48 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control: make sliders aware of context
Description:
A given setting in a radio might be dependent on other settings. For example, a radio might offer a filter that changes parameters depending on the transmission mode; or a particular setting might be disabled when another setting is enabled.

Presently, slider controls work by reading a setting from the radio and showing that setting in the slider. If the user changes the slider's position, commands are sent to the radio to adjust the setting the slider represents. We should consider enhancing the product to make sliders aware of context; they can disable or enable based on other settings; or change ranges or labels based on other settings.

One application of this feature is given in the related issue, involving the SH command (for filter width) on some Yaesu radios. Depending on mode, the filter setting might accept different ranges of values, have different defaults, or be completely irrelevant. A good, generic implementation of a context-aware slider control would enable robust emulation of the radio's front panel, and accurate descriptive control of the radio's features.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2969 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-12-06 13:51 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.131  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Rig Control: consider "selector" button style
Description: Rig Control shows an array of buttons and sliders to control the radio. These work pretty well to emulate the radio's front panel, but I think another control woudl be uself: a selector button.

A selector button is small, like the presently available on/off buttons. It shows a small amount of text. When pressed, the button moves to the next mode of that setting. It probably changes its text to reflect that setting.

An example might be an "ATT" button, for attenuation. The button shows "ATT -6dB". When pressed, the radio is set to the next level of attenuation, maybe -12 db. The button now shows "ATT -12dB". Each press cycles the radio and the button's text to the next setting: "-12 dB", then "-15 dB", then "off", then "-3 dB", then back to "-6 dB".

Most radios already have buttons like this that cycle through a list of settings. What I describe here is exactly how the "ATT" button on the front panel of the FTDX 3000 works, for example.

This kind of button is smaller than a drop-down button, but doesn't allow the setting to be randomly selected; the user must cycle through to find their setting and can't pick it from a list. This button can represent states other than "on" or "off".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2968 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-12-06 13:51 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.131  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Rig Control: layout only allows for six drop-down controls
Description: The top third of the radio view in Rig Control has an array of buttons, along with a few meters and a frequency display. The on/off buttons are configurable: they might be removed or added from a list of available features; their color can be changed, too. There's room for about

Drop-down buttons, if not hidden, appear in a single column on the right hand side of the view. There's only room for six, which is limiting because, as radios become more complex, it is useful to express more features in with drop-down buttons.

To add support for more drop-downs, the customization dialog has to become more flexible. There's a few things that need to happen, maybe more:


  • Find a way to enumerate the available drop-downs; this allows the unused ones to appear in the window so they can be dragged to an appropriate place

  • Sort out a good UI so that a user can place a drop-down where two buttons are. It would be nice if manual movement or re-ordering was kept to a minimum.

  • Make serialization of the settings work for the new (additional) layout.

  • Make settings serialization also convert from the old layout format.



Probably a few other things need to be sorted, too ... but I think this is an important fix because even mid-range radios have more than 6 settings which would benefit from having a drop-down to control the setting.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2944 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-11-16 19:17 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control: add support for FT-818
Description: This new Yaesu rig is probably the same as the FT-817ND as far as HRD is concerned, but we should support it by name in the UI and get it tested to make sure it has first-class treatment.
Tags: FT-818, Yaesu
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2939 [2 - Next Dev List (Holding Area)] Bug minor always 2018-11-09 18:31 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.901  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: Logbook's Query feature is not documented
Description:
The Logbooks supports using a query to filter the values shown in the Logbook's row view. The query feature is different than the filter feature. The Query filter is accsessed from the "Query" command in the "Logbook" menu, as well as the "Selection" group in the "Display" pane in the left side of each Logbook view window.

The documentation doesn't cover the Query feature at all. It should be documented so that users know it exists, and know how to use it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2938 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2018-11-07 20:52 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.900  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control: some IC-7851 buttons not working, missing
Description: A customer made a report about some buttons for the IC-7851 not working or being correctly labelled in Rig Control.

These concerns aren't particularly easy to fix as I don't have access to an IC-7851.

This was originally entered as a note 2710, and separated here for more effective tracking.
Tags: IC-7851, ICOM
Steps To Reproduce:
Additional Information: Customer comment:
I just made a smoke test:

1. I see the buttons now – and they work!, as far as I was able to test them in the short time.
2. At a first glance, I am missing some buttons:

a. The MP-W and the MP-R buttons; I like to use them quite often.

b. The V/M button; you replaced it with the two buttons VFO and MEM ?

c. The M = S button should rather read M > S;
 on the 7851 front panel, this button always copies from M to S, independently of which receiver (main or sub) is active.

d. The APF button; on the “real” 7851 it is combined with the TPF button. In your HRD layout it is missing.
 However, I accept that this APF button is not so important to see it in HRD since this function is depending to the adjustment of the allocated knob on the TRX’ front panel.

e. It would be nice to have the “Main” and “Sub” button side by side instead of one above the other. This would be more like the arrangement on the 785’1 front panel.

f. In my 7851, I have inhibited to be able to switch the antenna matrix via remote control – for safety reasons. It would however be nice to be able to toggle between the programmed TX Antenna (1, 2, 3 or 4) to the RX-I/O antenna .
 This is a function I use very often during contesting.


3. There may be more nice “cosmetics” possible. For the moment I am happy to see the working buttons in HRD. Congratulations!
Attached Files:
Notes
(0007055)
PD9FER   
2019-01-21 06:03   
Ticket #350643
Got a new report:
At the moment some sliders (e.g. Treble / Bass) at my RIG CONTROL are not working with my IC-7851

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2930 [2 - Next Dev List (Holding Area)] Bug minor always 2018-11-01 23:33 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.899  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Documentation
Testing: Not Started
Summary: Documentation: "Split" feature of DX Cluster is undocumented
Description: The product documentation includes no information about the split feature of the DX Cluster
Tags:
Steps To Reproduce:
1) Read the docs for the Logbook, looking for "Split" (or QSX, or any other term you might guess ...)
BUG#1) Find nothing.

Additional Information:
Attached Files: QSX HK0RMR.PNG (26,373 bytes) 2019-01-27 22:31
https://development.hamradiodeluxe.com/file_download.php?file_id=663&type=bug
png
Notes
(0007093)
WA9PIE   
2019-01-27 22:31   
In my opinion, the previous developers took a request from users and then took action on it without gathering (or ignoring) details. As such, it's FAR harder than it should be.

There's another aspect of this problem that was not covered in the initial implementation that has to do with SENDING split spots. We do NOTHING about sending split spots. It's appropriate to discuss SENDING spots first. Then I'll discuss actions taken on those spots.

Let's make this simple:

The correct way to communicate a split frequency in the DX cluster is by using QSX.

Example - "QSX 7024.2" is the correct way to announce the TX frequency for split.

The format for sending spots is: dx [by <call>] <freq> <call> <remarks>

In this example, the software would send something like this: "dx na4j 7014.0 QSX 7024.2" (without quotes) [Image attached of what that would look like in Logbook's Send DX Spot dialog box.]

The CC11 string received by a DX Spider node would look like this:
CC11^7014.0^HK0RMR^27-Jan-2019^2303Z^QSX 7024.2^NA4J^78^226^K4JW^11^7^8^4^ ^NC^San-Andres-Providencia-HK0/A^Alabama-K^^EM96

So here's problem #1 - we don't SEND the split frequency... at all. If we expect to be able to take actions on split spots in the DX cluster pane, we need to send in the proper format.

NOTE: When do we send this QSX thingie? We send QSX when the user's rig is in Split mode and they attempt to send a spot. This adds at least two steps to the current process. One - we check to see if the radio is in split mode. If so - then two, we get the frequency from the TX VFO and pop it into the "Remarks" field with "QSX " inserted in front of it. We allow the user to change what's in the remarks field (often they may append text to it).

The reason why this is so important is that it eliminates the random variation of how split is announced. It also makes it easier for the user.

Okay... so that covers the sending part.

Then - to cover current functionality in the DX cluster pane - we should get rid of all other methods for parsing out split except for two.

One - when the Remarks field contains "QSX frequency", we should set the TX VFO and put the radio in split.

And two - only because it's common we should also honor "up x" or "dn x"... where x is an integer that is added to the RX frequency and that is what's used to set the TX VFO. (As I say, only because it's common... not because I think it's a good idea.)

Sticking with our example, if we receive the following CC11 string:

CC11^7014.0^HK0RMR^27-Jan-2019^2303Z^up 10.2^NA4J^78^226^K4JW^11^7^8^4^ ^NC^San-Andres-Providencia-HK0/A^Alabama-K^^EM96

This should have the same effect. that is... the RX frequency (7014.0) plus the "up" (10.2) = the TX VFO frequency (7024.2).

Trying to parse anything else is a complete mess and should be avoided.
(0007108)
K7ZCZ   
2019-01-28 14:57   
This issue is about updating the customer-facing documentation for the feature. If there are prolems in the implementation, I think those issues should be raised in their own Mantis issue (or issues). When Mantis isuses start tracking multiple issues, they get a lot harder to manage, track, and work.
(0007114)
WA9PIE   
2019-01-29 02:36   
I can understand the need to split things up. That said, I don't think anyone can write documentation for a feature that (a) no one really knows how it was coded or implemented and (b) bares no resemblance to how it should actually work. It would be a complete guess. If I knew how it was coded and/or implemented, I suppose I could attempt to document the "as-is" state of this feature. But I would immediately want to change it to make it usable and less complicated.

My gut feeling is that there's much more in this than just the standard QSX and up/dn x. But I don't know. If a review of the code reveals that these are the only methods implemented, then WOW... that's great! I'll write the documentation for that and we'll work up the SEND part in a separate Mantis enhancement issue. But as I say... I really doubt it was done this way.

Let me know how you would like to proceed. I think this is an important item.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2881 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-09-06 19:22 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.881  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Interfacing
Testing: Not Started
Summary: Logbook: should warn user when closing UDP-listening databases
Description:
The logbook can be configured to listen for QSO notifications on a couple UDP ports. When those databases are closed in the UI, the listening stops. Users should be warned when closing a database that's active for listening.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2880 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-09-06 19:21 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.881  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Logbook: status bar should show status
Description: The Logbook has several background tasks and connections:


  • connect to rig control

  • connect to DM780

  • listen to QSO forwarding (two ports)

  • send QSO forwarding

  • "CLI" interface on TCP/IP



The state of these feautres is pretty much hidden. There's some logging, but it requires reading (and understanding) text messages in a few different windows.

The Logbook should add some code to mark the statues (and some activity, if appropriate) of the various connections it manages in the status bar.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2870 [2 - Next Dev List (Holding Area)] Bug crash always 2018-09-01 19:46 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.877  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: crashes when connecting to down MySQL server instance
Description: The MySQL ODBC drivers cause the Logbook to crash if the Logbook is configured to use a MySQL database that's not available at the startup of the Logbook. The Logbook crashes, but the problem is that the Logbook's code (inside MFC, actually -- internal to the library) queries the MySQL ODBC driver for error information. When it does so, the drivers cause a crash instead of returning a useful error message.

The callstack shows that the crash is when the Logbook tries to connect to the database (with the OpenEx() call). There's no way for the Logbook to know not to make that call -- it has to make that call, and expects an exception or a failure to be reported.
Tags:
Steps To Reproduce: 1) Start up the Logbook
2) Configure the Logbook to use a MySQL server instance
3) Set that MySQL Server instance as the Default database
4) Close the Logbook
5) Stop your MySQL server instance
6) Start the Logbook

BUG#1) Crash at startup with the attached call stack
Additional Information:
     odbc32.dll!_SQLErrorW@32()	Unknown
     HRDLogbook.exe!CDBException::BuildErrorString(CDatabase * pdb=0x0ecda204, void * hstmt=0x00000000, int bTrace=1) Line 142	C++
     HRDLogbook.exe!AfxThrowDBException(short nRetCode=-1, CDatabase * pdb=0x0ecda204, void * hstmt=0x00000000) Line 60	C++
     HRDLogbook.exe!CDatabase::ThrowDBException(short nRetCode=-1) Line 38	C++
     HRDLogbook.exe!CDatabase::Connect(unsigned long dwOptions=12) Line 808	C++
     HRDLogbook.exe!CDatabase::OpenEx(const wchar_t * lpszConnectString=0x17853728, unsigned long dwOptions=12) Line 299	C++
>	HRDLogbook.exe!CBackgroundProcessingThreadLookups::DatabaseList(HWND__ * const hWnd=0x00000000, CLogbookDatabases * pList=0x0ed13130) Line 902	C++
     HRDLogbook.exe!CDXClusterDlg::LookupThreadProc(void * pParam=0x0cf9edb0) Line 339	C++
     HRDLogbook.exe!_callthreadstartex() Line 376	C
     HRDLogbook.exe!_threadstartex(void * ptd=0x0cfa7e10) Line 359	C
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown
Attached Files:
Notes
(0006047)
K7ZCZ   
2018-09-01 19:47   
I'm using MyODBC5W version 5.3.10

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2869 [2 - Next Dev List (Holding Area)] Bug minor always 2018-09-01 17:36 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.877  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Documentation: online help text in QSO Forwarding window should be corrected, updated
Description:
The documentation visible in the QSO Forwarding window doesn't match the actual content of the window. The text should be re-written and replaced.

Tags:
Steps To Reproduce: 1) Fire up the Logbook
2) Use the "QSO Forwarding" command in the "Configuration" tear- off under the "Tools" menu
3) in the resulting "QSO Forwarding" dialog, check out the help text at the bottom of the window.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2868 [2 - Next Dev List (Holding Area)] Bug minor always 2018-09-01 16:24 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.877  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: (select)
Testing: Not Started
Summary: Documentation: should be updated for new QSO Forwarding options UI
Description: The QSO Forwarding documentation appears at this link: https://wiki.hamradiodeluxe.com/index.php?title=Logbook#QSO_Forwarding

The documentation shoudl be updated to reflect the new UI and the options it describes
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2857 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-08-24 12:36 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.843  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: LoTW
Testing: Not Started
Summary: Logbook: Crash while uploading to LOTW
Description: Not a strong repro case because this comes from the Dev Dashboard. We find a stack where the user crashes while updating the LOTW account from the Logbook.

The code in question is reached like this. A working LOTW account is required, and that requires some set up in the Logbook application.

1) Open a Logbook database
2) Select at least on record
3) Use the "More" button in the database view toolbar
4) In the dropdown, use the "Upload" command in the "LOTW" tear-off

The resulting window has an "Upload" button.

The call stack shows that command being processed and looping through the selected records. There might be some change in the rows store while this loop is running, or there could be a change in selection, too -- but it seems like the application encounters a bad pointer returned from the row store as the loop tries to run.

A spreadsheet with the populated call stack is attached.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2857Stack.xlsx (15,254 bytes) 2018-08-24 12:36
https://development.hamradiodeluxe.com/file_download.php?file_id=523&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2855 [2 - Next Dev List (Holding Area)] Bug minor always 2018-08-23 09:56 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.876  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: General
Testing: Not Started
Summary: Logbook: CGetWebPage class leaks web request handle
Description: The Logbook's use of the CGetWeBpage class causes a handle leak, which is detected at application shutdown by App Verifier.
Tags:
Steps To Reproduce: Found with App Verifier.
Additional Information:

=======================================
VERIFIER STOP 00000900: pid 0x4A08: A heap allocation was leaked. 

    20E34AC0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
    085521FC : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
    22C48BD0 : Address of the owner dll name. Run du <address> to read the dll name.
    26D40000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.


=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

(4a08.3b88): Break instruction exception - code 80000003 (first chance)
eax=62460360 ebx=00000000 ecx=000001a1 edx=009bee51 esi=0f842c18 edi=20e34ac0
eip=62453ae8 esp=009bf040 ebp=009bf254 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200202
vrfcore!VerifierStopMessageEx+0x5b8:
62453ae8 cc              int     3
0:000> dps 85521fc
085521fc  087eb314
08552200  0000e001
08552204  000c07b6
08552208  0f2fc57a verifier!AVrfpDphNormalHeapAllocate+0xba
0855220c  0f2facda verifier!AVrfDebugPageHeapAllocate+0x36a
08552210  778127bb ntdll!RtlpNtSetValueKey+0x34bb
08552214  77775889 ntdll!RtlAllocateHeap+0x10d9
08552218  77774979 ntdll!RtlAllocateHeap+0x1c9
0855221c  777747ee ntdll!RtlAllocateHeap+0x3e
08552220  6245ac7a vrfcore!VfCoreRtlAllocateHeap+0x2a
08552224  0f83822c vfbasics!AVrfpRtlAllocateHeap+0xdc
08552228  26e57389 msjet40!malloc+0x49
0855222c  26e4712f msjet40!yy_create_buffer+0x44
08552230  26e47641 msjet40!yylex+0x8f
08552234  26e4caf4 msjet40!SQLConvertString+0x148
08552238  0f832244 vfbasics!AVrfpKernel32CreateFileA+0x34
0855223c  26e53601 msjet40!JetCreateFileW+0xa1
08552240  729bebce WINHTTP!WinHttpSendRequest+0x48e
08552244  0dd289f4*** WARNING: Unable to verify checksum for C:\Ham Radio\Debug\HRDStation.dll
 HRDStation!GetWebFile+0x4a4 [c:\ham radio\hrdstation\getwebfile.cpp @ 168]
08552248  0dd29b09 HRDStation!HRDGetWebFileW+0x39 [c:\ham radio\hrdstation\getwebfile.cpp @ 51]
0855224c  01b5566d HRDLogbook!CGetWebPage::Get+0xcd [c:\ham radio\logbook\hrdlogbook\getwebpage.cpp @ 67]
08552250  01a579f6 HRDLogbook!CBackgroundProcessingThread::LoadURL+0x56 [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadloadurl.cpp @ 22]
08552254  01a4dd8d HRDLogbook!CBackgroundProcessingThread::ProcessData+0x1bd [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthread.cpp @ 480]
08552258  01a4d22f HRDLogbook!CBackgroundProcessingThread::DoWork+0x11f [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthread.cpp @ 302]
0855225c  01d67ec9 HRDLogbook!CThinThread::Run+0xd9 [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 188]
08552260  01d67fda HRDLogbook!CThinThread::Start+0x6a [c:\ham radio\logbook\hrdlogbook\thinthread.cpp @ 227]
08552264  023459b1 HRDLogbook!_callthreadstartex+0x51 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376]
08552268  02345c11 HRDLogbook!_threadstartex+0xb1 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 359]
0855226c  0f833538 vfbasics!AVrfpStandardThreadFunction+0x48
08552270  75408484 KERNEL32!BaseThreadInitThunk+0x24
08552274  77792fea ntdll!RtlValidSecurityDescriptor+0x11a
08552278  77792fba ntdll!RtlValidSecurityDescriptor+0xea


Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2853 [2 - Next Dev List (Holding Area)] Bug minor always 2018-08-23 09:55 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.876  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: DX Cluster
Testing: Not Started
Summary: Logbook: list of DXClusterFilters leaks XML object
Description:
App Verifier detects that an XML document related to the DX Cluster Filter object is leaked at shutdown.

Tags:
Steps To Reproduce:
Found with App Verifier.
Additional Information:
=======================================
VERIFIER STOP 00000202: pid 0x4A08: Freeing heap block containing an active critical section. 

    1539B22C : Critical section address. Run !cs -s <address> to get more information.
    0850E574 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
    1539B220 : Heap block address.
    0000002C : Heap block size.


=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

(4a08.bd4): Break instruction exception - code 80000003 (first chance)
eax=22ca0cb0 ebx=00000000 ecx=000001a1 edx=270ced11 esi=0f8444c8 edi=1539b22c
eip=62453ae8 esp=270cee7c ebp=270cf090 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
vrfcore!VerifierStopMessageEx+0x5b8:
62453ae8 cc              int     3
0:015> dps 0850e574
0850e574  00000000
0850e578  0000a001
0850e57c  0015030b
0850e580  0f829603 vfbasics!AVrfpInitializeCriticalSectionCommon+0xf6
0850e584  0f829751 vfbasics!AVrfpRtlInitializeCriticalSection+0x11
0850e588  6526cb15 msxml6!SafeInitializeCriticalSection+0x18 [onecore\enduser\sql\xml\msxml6\core\base\mt.cxx @ 99]
0850e58c  652703cc msxml6!X_CRITICAL_SECTION::Initialize+0x11 [onecore\enduser\sql\xml\msxml6\core\base\mt.cxx @ 114]
0850e590  652695c0 msxml6!Document::init+0x90 [onecore\enduser\sql\xml\msxml6\xml\om\document.cxx @ 172]
0850e594  65244aa9 msxml6!_createDOMDocument+0x1d [onecore\enduser\sql\xml\msxml6\xml\om\xmldocument.cxx @ 29]
0850e598  65244bba msxml6!CreateDOMDocument+0x3a [onecore\enduser\sql\xml\msxml6\xml\om\xmldocument.cxx @ 67]
0850e59c  65244e06 msxml6!ClassFactory::CreateInstance+0x66 [onecore\enduser\sql\xml\msxml6\core\com\classfactory.cxx @ 66]
0850e5a0  770db6d5 combase!ICoCreateInstanceEx+0x665 [onecore\com\combase\objact\objact.cxx @ 1823]
0850e5a4  770daec5 combase!CComActivator::DoCreateInstance+0x175 [onecore\com\combase\objact\immact.hxx @ 394]
0850e5a8  770daccd combase!CoCreateInstance+0xad [onecore\com\combase\objact\actapi.cxx @ 121]
0850e5ac  01da72f0 HRDLogbook!CXMLMgr::Initialize+0x40 [c:\ham radio\hrdcommon\xmlmgr.cpp @ 342]
0850e5b0  01afe5f9 HRDLogbook!CDXClusterFilters::Load+0x99 [c:\ham radio\logbook\hrdlogbook\dxclusterfilters.cpp @ 426]
0850e5b4  01b64037 HRDLogbook!CHRDLogbookApp::InitInstance+0xc47 [c:\ham radio\logbook\hrdlogbook\hrdlogbook.cpp @ 700]
0850e5b8  02c2b52e HRDLogbook!AfxWinMain+0xae [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
0850e5bc  02c2a9f8 HRDLogbook!wWinMain+0x18 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\appmodul.cpp @ 26]
0850e5c0  02332208 HRDLogbook!__tmainCRTStartup+0x128 [f:\dd\vctools\crt\crtw32\startup\crt0.c @ 251]
0850e5c4  023323ed HRDLogbook!wWinMainCRTStartup+0xd [f:\dd\vctools\crt\crtw32\startup\crt0.c @ 165]
0850e5c8  75408484 KERNEL32!BaseThreadInitThunk+0x24
0850e5cc  77792fea ntdll!RtlValidSecurityDescriptor+0x11a
0850e5d0  77792fba ntdll!RtlValidSecurityDescriptor+0xea
0850e5d4  085cd574
0850e5d8  0000c000
0850e5dc  00190000
0850e5e0  084a96a0
0850e5e4  0f2fae23 verifier!AVrfDebugPageHeapFree+0xe3
0850e5e8  77812ff1 ntdll!RtlpNtSetValueKey+0x3cf1
0850e5ec  777726f5 ntdll!RtlGetCurrentServiceSessionId+0xf5
0850e5f0  777722c2 ntdll!RtlFreeHeap+0x222
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2848 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-08-22 19:06 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.876  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: (select)
Testing: Not Started
Summary: Digital Master: crashes when logging from sound processing thread
Description:
No repro, since this is a set of dumps that I picked up from the Dev Dashboard.

The sound background processing thread is ending up at abort() to shut down the application after a call to Log().Add() to log a string. From the disassembly, I can see that the call to Log().Add() is made at both call stacks, leaving the return address one layer down in the reported stack. However, I can't figure out how (or for what cause) a call to Log().Add() would result in a call to abort().

Perhaps there's another layer of fast failure handling inbetween and that's causing me to miss the call.

Reports found for 843 and 876. One spreadsheet is attached from each build with a populated stack.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2848Stack Build 843.xlsx (9,524 bytes) 2018-08-22 19:08
https://development.hamradiodeluxe.com/file_download.php?file_id=519&type=bug
Mantis2848Stack Build 876.xlsx (9,605 bytes) 2018-08-22 19:08
https://development.hamradiodeluxe.com/file_download.php?file_id=520&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2843 [2 - Next Dev List (Holding Area)] Bug minor always 2018-08-16 19:40 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.876  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: allows same database back-end store to be used multiple times at the same time
Description:
1) Fire up the logbook
2) Click on the Manager button in the main toolbar to launch the Databases Manager
3) Use the "ODBC administrator" button to add a new Access database. Store it wherever you'd like; name it whatever you'd like.
4) Use the "Add" button in the "Logbook Databases" dialog to add a new database using the ODBC connection you built in Step 3.
5) Use the "Add" button in the "Logbook Databases" dialog again, adding a new database with a different name than Step 4, but the same ODBC data source as Step 3.

The Logbook thinks this configuration is fine; in a way, it is. But the problem is that the user can end up opening the same ODBC database more than once in the logbook, and that is quite confusing for users. They feel like the name shown in the Logbook (which is the name specified creating the connection, in Step 4 or Step 5, not the ODBC data source name from Step 3) is the name of the database. If the names are different, they think the connections (or tabs, in the UI) represent different databases.

They'll notice that adding a record to one database adds a record to the other at the same time; or that deleting or editing one does the same operation in the other.

To resolve this issue, we need to do some design and make some decisions about UI. How can we detect duplicate stores when ODBC insulates the application from the physical details of the connection? How should we inform users of the error in existing configurations? What's the best way to indicate to users that they've created (or are creating) a bogus configuration, and prevent them from doing so?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: BadConfig.png (16,970 bytes) 2018-08-16 19:42
https://development.hamradiodeluxe.com/file_download.php?file_id=514&type=bug
png
Notes
(0005982)
K7ZCZ   
2018-08-16 19:42   
This screenshot shows two databases configured against the same Access back-end. "HRD Access Bogus" and "HRD Access Good" are both referencing the "MS Access Database" ODBC config, and therefore using the same Access database instance.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2842 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-08-16 19:00 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.873  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: Macros
Testing: Not Started
Summary: Digital Master: crash in form frame when processing tags
Description:
Another identifiable report from the Dev Dashboard, so no repro steps -- just a static call stack.

Looks like DM780 is crashing when handling the "NewMacros" message; this message is sent and reflected all over the place in a byzantine fashion. The cause might be similar in shape to that in 2825, when a window is closed and the StandardFrame loses track of its related StandardView, but the call stack is quite different.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2842Stack.xlsx (13,532 bytes) 2018-08-16 19:01
https://development.hamradiodeluxe.com/file_download.php?file_id=513&type=bug
Notes
(0005981)
K7ZCZ   
2018-08-16 19:01   
Spreadsheet with annotated stack is attached

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2827 [2 - Next Dev List (Holding Area)] Maintenance minor always 2018-08-04 22:54 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.873  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Install
Testing: Not Started
Summary: Setup: ships with old Access 2007 runtime
Description: Setup contains (but does not install (see Mantis 2099) the Access 2007 runtime.

The currently available version of the Access engine is 2016. There's no reason to not install this version, as it's compatible with all the operating systems we support.

Once we make a decision about fixing 2099, we should upgrade to a current version of the Access runtimes.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2825 [2 - Next Dev List (Holding Area)] Bug crash always 2018-08-02 19:02 2020-07-02 02:12
Reporter: K7ZCZ Platform: Intel i7-5960X  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 16299  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: QSO Window
Testing: Not Started
Summary: Digital Master: crashes when closing QSO window
Description:
The call stack given below is from a debug version of the product, where I first noticed this problem. But it ocurrs in release, no problem. The CStandardFormInput window isn't managing multiple instances of the QSO window correctly.
Tags:
Steps To Reproduce:
1) Fire up Digital Master. Doesn't need a radio connection
2) Create a CW QSO window (if one doesn't already exist) with the "QSO" button in the toolbar
3) Create another (second) CW QSO window
4) Close the first window by clicking the "X" in the tab of the window pane

BUG#1) DM crashes with a minidump.
Additional Information:
     Digital Master.exe!CStandardFormFrame::CompleteMacro(const ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > & strRaw={...}, const int bAddRTF=0) Line 1405	C++
>	Digital Master.exe!CTxRichEditCtrl::CheckNewTags(CStandardFormFrame * pFrame=0x1212f610, CSuperBrowserFrame * pSuper=0x00000000) Line 1727	C++
     Digital Master.exe!CStandardFormInput::OnNewTagValue(unsigned int wParam=0, long lParam=0) Line 3142	C++
     Digital Master.exe!CStandardFormInput::OnNewMacros(unsigned int wParam=0, long lParam=1) Line 3404	C++
     Digital Master.exe!CWnd::OnWndMsg(unsigned int message, unsigned int wParam=0, long lParam=1, long * pResult=0x007cf904) Line 2679	C++
     Digital Master.exe!CWnd::WindowProc(unsigned int message=51182, unsigned int wParam=0, long lParam=1) Line 2094	C++
     Digital Master.exe!AfxCallWndProc(CWnd * pWnd=0x12555008, HWND__ * hWnd=0x00101b7e, unsigned int nMsg=51182, unsigned int wParam=0, long lParam=1) Line 285	C++
     Digital Master.exe!AfxWndProc(HWND__ * hWnd=0x00101b7e, unsigned int nMsg=51182, unsigned int wParam=0, long lParam=1) Line 434	C++
     user32.dll!__InternalCallWinProc@20()	Unknown
     user32.dll!UserCallWinProcCheckWow()	Unknown
     user32.dll!DispatchMessageWorker()	Unknown
     user32.dll!_DispatchMessageW@4()	Unknown
     Digital Master.exe!AfxInternalPumpMessage() Line 183	C++
     Digital Master.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00da7e28, HINSTANCE__ * hPrevInstance=0x00000001, wchar_t * lpCmdLine=0x00000000, int nCmdShow=8190912) Line 47	C++
     Digital Master.exe!__tmainCRTStartup() Line 251	C
     kernel32.dll!@BaseThreadInitThunk@12()	Unknown
     ntdll.dll!__RtlUserThreadStart()	Unknown
     ntdll.dll!__RtlUserThreadStart@8()	Unknown
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2821 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-07-28 11:31 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: Rig control: crash when reading on/off commands
Description:
I don't have a repro for this, and pretty scarce information, as the issue is collected form the Microsoft Dev Center. The dashboard reports a pretty frequent crash in Rig Control when calling ReadOnOffCommoon() in CRadioOptions.

The crash is attached as as a spreadsheet. I'm afraid the call stack isn't completely accurate, as the ReadOnOffCommon() doesn't directly call abort(). Perhaps there's a hidden call to abort(), or maybe the call stack got trashed and I'm missing a frame or two.

According to the dashboard, this is a frequent cause of crashes so I want to record it and collect evidence and see what we can do.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2821.xlsx (13,195 bytes) 2018-07-28 11:32
https://development.hamradiodeluxe.com/file_download.php?file_id=481&type=bug
Mantis2821Stack2.xlsx (13,270 bytes) 2018-08-15 07:51
https://development.hamradiodeluxe.com/file_download.php?file_id=510&type=bug
Mantis2821Stack893.xlsx (9,805 bytes) 2018-10-22 23:25
https://development.hamradiodeluxe.com/file_download.php?file_id=574&type=bug
Mantis2821Stack903_2.xlsx (12,408 bytes) 2018-12-01 08:26
https://development.hamradiodeluxe.com/file_download.php?file_id=590&type=bug
Mantis2821Stack903_1.xlsx (9,623 bytes) 2018-12-01 08:26
https://development.hamradiodeluxe.com/file_download.php?file_id=591&type=bug
Mantis2821Stack903_3Icom.xlsx (9,626 bytes) 2018-12-01 12:47
https://development.hamradiodeluxe.com/file_download.php?file_id=593&type=bug
Notes
(0005906)
K7ZCZ   
2018-08-02 18:57   
This check in refactors the KenwodReadString() function a bit so that debugging this issue might be a little easier.

https://hrdsoftware.visualstudio.com/web/cs.aspx?pcguid=024933d8-393e-4d7b-806f-280bdbd42f73&cs=4262
(0005978)
K7ZCZ   
2018-08-15 07:51   
Here's another stack trace for the same issue; slightly different call site pattern, reported against build 873. The fix I made on August 2 is not in build 873. It first appears in build 874 beta, and 876 release.
(0006333)
K7ZCZ   
2018-10-22 23:25   
The refactoring helps just a bit, but still no conclusion. The attached stack is from the 893 build. This is a common crash, about 17% of the crashes for RigControl, according to the Microsoft dashboard.

It seems a call to a checked string function is going out of range, but I have no smoking gun because the stack trace has a bit of a funny shape.
(0006500)
K7ZCZ   
2018-12-01 08:26   
This is still happening in 903. Two stacks are attached; very different paths, but they're both heading for KenwoodReadString() and end up calling abort().
(0006507)
K7ZCZ   
2018-12-01 12:47   
The attached Mantis2821Stack903_3Icom spreadsheet has a similar crash but is against an Icom radio.

The call site before the crash is here:
0:000> u
HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e41 [c:\ham radio\hamradiodeluxe\radiooptions.cpp @ 19277]:
0051f731 81fe80220000    cmp     esi,2280h
0051f737 72cb            jb      HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e14 (0051f704)
0051f739 e9e2000000      jmp     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2f30 (0051f820)
0051f73e 8d347f          lea     esi,[edi+edi*2]
0051f741 8a04f588d0a200  mov     al,byte ptr HamRadioDeluxe!aButtonsOnOffCIV2+0x8 (00a2d088)[esi*8]
0051f748 8a0cf589d0a200  mov     cl,byte ptr HamRadioDeluxe!aButtonsOnOffCIV2+0x9 (00a2d089)[esi*8]
0051f74f 8a14f58ad0a200  mov     dl,byte ptr HamRadioDeluxe!aButtonsOnOffCIV2+0xa (00a2d08a)[esi*8]
0051f756 88442478        mov     byte ptr [esp+78h],al
0:000> u
HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e6a [c:\ham radio\hamradiodeluxe\radiooptions.cpp @ 19285]:
0051f75a 888c24ac000000  mov     byte ptr [esp+0ACh],cl
0051f761 88942424010000  mov     byte ptr [esp+124h],dl
0051f768 84c0            test    al,al
0051f76a 7513            jne     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e8f (0051f77f)
0051f76c 84c9            test    cl,cl
0051f76e 750f            jne     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e8f (0051f77f)
0051f770 8b442418        mov     eax,dword ptr [esp+18h]
0051f774 8b905c010000    mov     edx,dword ptr [eax+15Ch]
0:000> u
HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2e8a [c:\ham radio\hamradiodeluxe\radiooptions.cpp @ 19296]:
0051f77a e977000000      jmp     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2f06 (0051f7f6)
0051f77f 80f9ff          cmp     cl,0FFh
0051f782 7513            jne     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ea7 (0051f797)
0051f784 3ad1            cmp     dl,cl
0051f786 752a            jne     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ec2 (0051f7b2)
0051f788 ff742478        push    dword ptr [esp+78h]
0051f78c 8b4c241c        mov     ecx,dword ptr [esp+1Ch]
0051f790 e80b3ef4ff      call    HamRadioDeluxe!CConnection::CIVReadStatus (004635a0)
0:000> u
HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ea5 [c:\ham radio\hamradiodeluxe\radiooptions.cpp @ 19304]:
0051f795 eb39            jmp     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ee0 (0051f7d0)
0051f797 80faff          cmp     dl,0FFh
0051f79a 7516            jne     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ec2 (0051f7b2)
0051f79c ffb424ac000000  push    dword ptr [esp+0ACh]
0051f7a3 8b4c241c        mov     ecx,dword ptr [esp+1Ch]
0051f7a7 ff74247c        push    dword ptr [esp+7Ch]
0051f7ab e81040f4ff      call    HamRadioDeluxe!CConnection::CIVReadStatus (004637c0)
0051f7b0 eb1e            jmp     HamRadioDeluxe!CRadioOptions::ReadOnOffCommon+0x2ee0 (0051f7d0)


The return address would be 51F7B0, but we end up at _abort() instead. That means the previous call, CConnection:CIVReadStatus(), either called (or called something that called) _abort. This is the same pattern in the other stacks, just that it's against an Icom radio instead of a Kenwood radio. The Icom code in CIVReadStatus() is far simpler than the similar code for the Kenwood radios.

In disassembling the CIVReadStatus() code, we don't find that too much work is done. As far as I can tell, the only function call in that implementation suspect of calling _abort() is the CString constructor. Here's the code:

0:000> u 004637c0
HamRadioDeluxe!CConnection::CIVReadStatus [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 902]:
004637c0 55              push    ebp
004637c1 8bec            mov     ebp,esp
004637c3 6aff            push    0FFFFFFFFh
004637c5 68f1889300      push    offset HamRadioDeluxe!OleUIAddVerbMenuW+0x8665 (009388f1)
004637ca 64a100000000    mov     eax,dword ptr fs:[00000000h]
004637d0 50              push    eax
004637d1 81ec2c010000    sub     esp,12Ch
004637d7 a1e0f1b600      mov     eax,dword ptr [HamRadioDeluxe!__security_cookie (00b6f1e0)]
0:000> u
HamRadioDeluxe!CConnection::CIVReadStatus+0x1c [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 902]:
004637dc 33c5            xor     eax,ebp
004637de 8945f0          mov     dword ptr [ebp-10h],eax
004637e1 53              push    ebx
004637e2 56              push    esi
004637e3 57              push    edi
004637e4 50              push    eax
004637e5 8d45f4          lea     eax,[ebp-0Ch]
004637e8 64a300000000    mov     dword ptr fs:[00000000h],eax
0:000> u
HamRadioDeluxe!CConnection::CIVReadStatus+0x2e [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 902]:
004637ee 8bf9            mov     edi,ecx
004637f0 6a01            push    1
004637f2 8d4728          lea     eax,[edi+28h]
004637f5 50              push    eax
004637f6 8d8dd8feffff    lea     ecx,[ebp-128h]
004637fc e854931600      call    HamRadioDeluxe!CSingleLock::CSingleLock (005ccb55)
00463801 6a01            push    1
00463803 8d4708          lea     eax,[edi+8]
0:000> u
HamRadioDeluxe!CConnection::CIVReadStatus+0x46 [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 904]:
00463806 c745fc00000000  mov     dword ptr [ebp-4],0
0046380d 50              push    eax
0046380e 8d8dccfeffff    lea     ecx,[ebp-134h]
00463814 e83c931600      call    HamRadioDeluxe!CSingleLock::CSingleLock (005ccb55)
00463819 c645fc01        mov     byte ptr [ebp-4],1
0046381d e8aed91400      call    HamRadioDeluxe!AfxGetStringManager (005b11d0)
00463822 33c9            xor     ecx,ecx
00463824 8bd0            mov     edx,eax
0:000> u
HamRadioDeluxe!CConnection::CIVReadStatus+0x66 [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 907]:
00463826 85d2            test    edx,edx
00463828 0f95c1          setne   cl
0046382b 85c9            test    ecx,ecx
0046382d 750a            jne     HamRadioDeluxe!CConnection::CIVReadStatus+0x79 (00463839)
0046382f 6805400080      push    80004005h
00463834 e8178ffaff      call    HamRadioDeluxe!ATL::AtlThrowImpl (0040c750)
00463839 8b02            mov     eax,dword ptr [edx]
0046383b 8bca            mov     ecx,edx
0:000> u
HamRadioDeluxe!CConnection::CIVReadStatus+0x7d [c:\ham radio\hamradiodeluxe\connectionciv.cpp @ 907]:
0046383d ff500c          call    dword ptr [eax+0Ch]
00463840 83c010          add     eax,10h
00463843 8985e8feffff    mov     dword ptr [ebp-118h],eax
00463849 0fb6450c        movzx   eax,byte ptr [ebp+0Ch]
0046384d 33db            xor     ebx,ebx
0046384f 50              push    eax
00463850 8b4508          mov     eax,dword ptr [ebp+8]
00463853 0fb6c0          movzx   eax,al



The most evident code we have is a branch that tests the pointer for the string manager to NULL and throws an exception if it is not found. The throw code starts at 0046382f. I've written a test program that does the same thing, forcing a null string manager. In a release build, that does throw an exception but the exception is handled by the unhandled filter and ends up calling abort from the filter rather than from the current stack. My test program crash looks like this:

0:000> kb
 # ChildEBP RetAddr  Args to Child              
00 00f5efb0 0101cbb8 4d0d5135 0101bc66 00000000 FormattingWidth!abort+0x28 [f:\dd\vctools\crt\crtw32\misc\abort.c @ 88] 
01 00f5efe0 0101bca6 00f5f084 74675cf0 00f5f0b4 FormattingWidth!terminate+0x33 [f:\dd\vctools\crt\crtw32\eh\hooks.cpp @ 96] 
02 00f5efe8 74675cf0 00f5f0b4 6353fea6 00000000 FormattingWidth!__CxxUnhandledExceptionFilter+0x40 [f:\dd\vctools\crt\crtw32\eh\unhandld.cpp @ 39] 
03 00f5f084 77b2d4e0 00f5f0b4 77afe822 00f5f854 KERNELBASE!UnhandledExceptionFilter+0x1a0
04 00f5f854 77af2ffa ffffffff 77b0ec42 00000000 ntdll!__RtlUserThreadStart+0x3a4e3
05 00f5f864 00000000 01015099 00cf5000 00000000 ntdll!_RtlUserThreadStart+0x1b



My guess was that the call pattern was crashing into abort() because manager wasn't available -- maybe this thread is untamed and running at shutdown, for example. But given this experiment, I'd have to expect a different call stack in that case.

We do know the call to _abort() eliminates some possibilities; it's not a call to _security_failure(), for example. Maybe the unhandled exception is the correct guess, or maybe there's something else that can call _abort() directly.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2820 [2 - Next Dev List (Holding Area)] Maintenance minor always 2018-07-28 11:16 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.873  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Various
Testing: Not Started
Summary: All: many calls to wcstombs_s() are incorrect, all are unnecessary
Description:
wcstombs_s() converts a wide ("Unicode") string to a multi-byte ("ANSI") string. Searching the suite for this API reveals about 175 call sites. Most of those calls have problems. For example,

// protoype for reference
errno_t wcstombs_s(size_t *pReturnValue, char *mbstr, size_t sizeInBytes, const wchar_t *wcstr, size_t count);  

// actual app code
wcstombs_s(&size, szPathName, MAX_PATH, dlg.GetPathName(), MAX_PATH);


this call passes the same value in (MAX_PATH) for the source and target length. If the string were really as long as MAX_PATH, the function would fail because the count parameter does include the null terminator, while the sizeInBytes parameter does. The security features in this function cause it to throw a fatal exception if the length mismatch occurs. That has the symptom of terminating the application without showing the user any UI.

Another pattern is the use of an absurdly large stack-allocated buffer, like this example from CConnection::KenwoodReadString() in Rig Control:

    CHAR szCharCmd[0x10000];
#ifdef _UNICODE
    {
        size_t size;
        wcstombs_s(&size, szCharCmd, ARRAYSIZE(szCharCmd), lpszCmd, wcslen(lpszCmd));
    }
#else
    StringCchCopyN(szCharCmd, ARRAYSIZE(szCharCmd), lpszCmd, strlen(lpszCmd));
#endif


MFC's CString hasbuilt-in handling for this conversion, as does the application's COwnString class. If the built-in handling is inadequate, it's much smarter to write reusable code and add it to COwnString (which is already used throughout the application) than it is to re-invent the wheel, mostly incorrectly, in 175 different places.

This issue is more than a coding style problem. Since the bad call sites have the potential to take down the application in a way that is very troubling for customers and isn't particularly easy to diagnose, we should come up with more sensible replacement.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006341)
K7ZCZ   
2018-10-23 16:40   
The same problem exists with calls to mbstowcs_s(). This example is from HRDStats.cpp:

    WCHAR wszName[512];
    size_t size;
    mbstowcs_s(&size, wszName, 512, lpszName, 512);
    wszName[size] = '\0';


If a string of 512 characters in length arrives, the function will throw a fatal exception because size will be set to 512, wszName[512] doesn't exist, and the value will be trapped.

As with the wcstombs_s() pattern, this bogus code idiom is copied-and-pasted throughout the code. In some instances, it can be replaced with a CString call that is correct and encapsulates the implementation. In some instances, care must be given to computing the length of the input string -- if the input string is too long, the resulting converted string will probably also be too long. In almost all cases, the code doesn't check the length of any string and is not robust to buffer-overflow input.
(0006344)
K7ZCZ   
2018-10-24 07:42   
incrementally addressed with these checkins; there is much more work to do:

https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4393
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4394

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2815 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-07-24 19:55 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: Logbook: Crashes when painting first column of item in Awards view
Description: I don't have a specific repro for this, as it was found by analyzing dumps reported to the Microsoft Dev Center Dashboard. This crash represents about 2% of the reported crashes in the Logbook.

The callstack is attached, given against the 840 build symbols. The crash happens when cloning a string from the awards definition in order to draw the first column of names in the view.

            CAward2Definition *pDefn = pAO->GetAwardsDef();
            if( !pDefn->m_astrAddCommands.IsEmpty() )
            {
                for( int i = 0; i < pDefn->m_astrAddCommands.GetCount(); ++i )
                {
                    CString strLine = pDefn->m_astrAddCommands.GetAt(i);     // line 1125
                    int iFind = strLine.Find(' ');
                    if( iFind >= 0 )



I haven't yet dug into the disassembly to see if it's possible that pDefn is actually NULL. Maybe it can't be, if it was previously dereferenced to get the count. Or, maybe the test for the empty array was optimized with the invariant of the for() loop, since they're similar calls and inline functions are available.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2815Stack.xlsx (14,840 bytes) 2018-07-24 19:56
https://development.hamradiodeluxe.com/file_download.php?file_id=475&type=bug
Mantis2815Stack Build 846.xlsx (11,434 bytes) 2018-08-22 14:15
https://development.hamradiodeluxe.com/file_download.php?file_id=518&type=bug
Notes
(0005992)
K7ZCZ   
2018-08-22 14:15   
Reports of the same crash are coming in against Build 846.
(0005993)
K7ZCZ   
2018-08-22 15:33   
pDefn isn't null; it seems more likely that the pDefn object is bogus or uninitialized. I did a deeper stack trace on the 846 build, and I notice that the very bottom of the stack trace is activating the Awards window from a CXTPTabClient window -- but that gets routed to a CXTPCalendarCaptionBar, which seems pretty weird.

I can't seem to repro that part of the call stack, so I can't yet guess how the user is interacting with the app when this crash occurs.
(0005994)
K7ZCZ   
2018-08-22 15:58   
A touch of refactoring -- just collect about 50 lines of copy-pasta in the Awards2View implementation.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4297

Nothing that fixes this issue, tho :(

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2745 [2 - Next Dev List (Holding Area)] Maintenance minor always 2018-05-25 22:13 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.840  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: General
Testing: Not Started
Summary: Logbook: Consider droping DDE support
Description: DDE is deprecated, barely supported by Micorosft. We should consider removing the DDE code from the product.
Tags:
Steps To Reproduce:
Additional Information: Deprecation:
https://blogs.msdn.microsoft.com/oldnewthing/20070226-00/?p=27863

Security Concerns:
https://technet.microsoft.com/library/security/4053440?f=255&MSPPError=-2147217396

Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2643 [2 - Next Dev List (Holding Area)] Bug minor always 2018-03-30 11:52 2020-07-02 02:12
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control: Preamp support isn't quite correct for IC-7610
Description:
Support for preamp settings on the IC-7610 in Rig Control isn't quite correct. The control lets the user switch between off, preamp 1, and preamp 2. That works, but it turns out that the Digi-Sel setting is exclusive to the operation of the preamps. The control should offer Off, Preamp 1, Preamp 2, and DigiSel settings.

Tags: IC-7610, ICOM
Steps To Reproduce:
Demonstrated by using an IC-7610:

1) Set Preamp to Pramp 1 on the touch screen
2) Press the Multi control to bring up the default menu
3) Press and hold the "DigiSel" on the menu. This turns DigiSel on, which turns the Preamp 1 setting off.


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2099 [2 - Next Dev List (Holding Area)] Bug major always 2017-07-05 14:30 2020-07-02 02:12
Reporter: K7ZCZ Platform: VMware VM  
Assigned To: OS: Windows 10 Professional x64  
Priority: normal OS Version: 10.0.15063  
Status: new Product Version: 6.4.0.647  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: Install
Testing:
Summary: Setup: does setup actually install Access runtime?
Description: I don't believe setup is installing the Access 2007 runtime.

The repro steps listed in this Mantis isuse demonstrate what I find on the builds I've tested (Build 647, Build 656, and Build 658).

If I manually install an Access runtime, I see the product listed in the Control panel "Programs And Features" UI. On none of the VMs I've used to test those builds do I see the Access runtime listed.

I'm not particularly familiar with InstallAware, but if I edit the source code I find a step that says "Check for Microsoft Access 2007 Runtime". This step doesn't seem to do any work and unconditionally sets a variable to TRUE.

The next step, which is called "Setup for Microsoft Access 2007 Runtime", tests that variable and only installs if it is set to FALSE.

Doesn't this mean that the code never tries to setup the Access 2007 run time?




Tags:
Steps To Reproduce: 1) Create a new Windows 10 VM
2) Install HRD on it
3) When setup is done, use Control Panel; select "Uninstall a program" under the "Programs" entry
4) The list of installed programs doesn't include any version of the Access runtime.

The attached screen shot shows the list I see.

Additional Information:
System Description Host machine is Windows 10 Pro x64 running on an Intel i7-5960X with 96 gigs of memory

Attached Files: SetupSetup.png (266,514 bytes) 2017-07-05 14:31
https://development.hamradiodeluxe.com/file_download.php?file_id=146&type=bug
SetupCheck.png (181,306 bytes) 2017-07-05 14:31
https://development.hamradiodeluxe.com/file_download.php?file_id=147&type=bug
png

SetupList.png (34,429 bytes) 2017-07-05 14:31
https://development.hamradiodeluxe.com/file_download.php?file_id=148&type=bug
png
Notes
(0003592)
K7ZCZ   
2017-07-08 17:24   
It seems like this changet "nerfed" access installation: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/3310
(0005068)
K7ZCZ   
2018-05-20 10:40   
100% sure at this point that setup is not _ever_ trying to install the Access runtime. We should talk over how we fix this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3261 [2 - Next Dev List (Holding Area)] Bug minor always 2019-03-26 12:50 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.199  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook describes all databases as "using Microsoft Access"
Description:
When creating a new Logbook Database, the Logbook will add a default description to the database that includes "Using Microsoft Access" even if the database isn't stored in an Access back-end.

This is wrong ... and can be pretty confusing.

Tags:
Steps To Reproduce:
1) Start up the Logbook.
2) Use the "Manager" button in the main toolbar to bring up the Logbook Databases dialog
3) In the "Logbook Databases" dialog, use the "ODBC Administrator" button
4) In the "ODBC Data Source Administrator" dialog, use the "Add..." button
5) In the resulting "Create New Data Source" dialog, select the MySQL driver
6) Press the "Finish" button
7) In the "MySQL Connector/ODBC Data Source Configuration" dialog, conifugre the data source for your server
8) Once configured, press the "OK" button
9) When you return to the "ODBC Data Source Administrator" dialog, press "OK"
10) In the Logbook Databases window, press the "Add" button in the toolbar
11) Type in any title you'd like; I chose "MySQL Test 3"
12) Press the "Advanced Options >>" button
13) In the revealed "Or Select for Repair" drop-down, choose the data source name you configured in Step #7
14) Press "OK"
15) The newly created database definition is added to the list in the "Logbook Databases" window

BUG#1) The new database has the description "MySQL Test 3 database using Microsoft Access", even though this database uses MySQL.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3259 [2 - Next Dev List (Holding Area)] Bug minor always 2019-03-24 09:53 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control doesn't support RIT or delta-TX functions on Icom radios
Description:
Most modern Icom radios support a bias setting for split CW work. The delta-TX and RIT settings allow adding a small offset to the receive and tx frequencies to adjust CW tone, fine tune offset for drift, and work zero-beat.

Rig Control doesn't support turning RIT or delta-RX on and off, and doesn't support setting or reading the bias frequency. Support for this useful feature should be added to Rig Control.

Tags:
Steps To Reproduce: See page 4-1 of the Icom IC-7610 basic manual (for example) to learn about the Receive Increment Tuning (RIT) and delta-TX settings
Additional Information:
It's not particularly hard to add on/off buttons to enable RIT or delta-TX. Just a couple buttons and the correspodning comands.

We don't have a good solution, though, for the Frequency offset control. The bias frequency has a range of-9.999 to +9.999 KHz. It's impractical to set this with a slider as just a change of few hertz is important in the setting and the sliders won't give great control over such a fine range.

While the range is very broad, most uses of the feature are within a few dozen hertz of the target frequency.

I suggest we implement this by offering "coarse" and "fine" slider controls. The fine control sets a frequency +/- 200 hertz from the target. It's centered at a 0 hz. All the way left is -200 hertz, all the way right is +200 hertz.

The coarse control adds a coarser bias of up to 9800 hertz in 200-hertz increments. All the way left, this control is at zero bias, and all the way right it's at 9800 hertz. The bias is in the same direction as the fine control, so this control isn't centered or signed.

For example:

Coarse: 0
Fine: -58
Setting: -58 hertz offset


Coarse: 400
Fine: -58
Setting: -458 hertz offset


Coarse: 0
Fine: +92
Setting: +92 hertz offset


Coarse: 600
Fine: 0 (centered)
Setting: +600 hertz offset


Coarse: 600
Fine: -1
Setting: -601 hertz offset



Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3252 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-03-18 15:18 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.196  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Break-in Delay is not displayed correctly for IC-7300 radios in Rig Control
Description:
A user has reported that Rig Control doesn't display the correct CW pitch for the IC-7300. See Ticket #474475.

Tags: IC-7300, ICOM
Steps To Reproduce: This report isn't quite as clear as some others offered in the ticket. Here's what we have:

<blockquote>

I also looked at some of the other slider controls you provide. Again, it is a relative scale and does not offer an indication of the actual value that is set. For break-in delay range I found as follows:

HRD Breakin delay 7300 actual

range 0 - 100 2d - 13d
</blockquote>
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3250 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-03-18 15:17 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.196  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Keyer speed is not correctly displayed for IC-7300
Description: A user reports (in ticket #474475) that the keyer speed for the IC-7300 is not displayed correctly by Rig Control.
Tags: IC-7300, ICOM
Steps To Reproduce:
The customer says:
<blockquote>
I reviewed the settings on the IC7300 and found that the key speed and side tone indicators are still inaccurate. They show a relative value from 0 to 100 and do not reflect the actual value for the settings. I also checked other settings and found others to be inaccurate as well. Here are my findings.

Key Speed (wpm):

HRD setting 7300 actual

0 6
10 10
22 15
33 20
45 25
56 30
80 40
98 48
</blockquote>
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3244 [2 - Next Dev List (Holding Area)] Bug minor always 2019-03-12 18:32 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.197  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Awards
Testing: Not Started
Summary: "Award 2 Definitions" dialog has a list that doesn't correctly sort item attributes
Description: Some award definitions are "locked" and can't be exported. Others are "unlocked" and can be exported.

The Logbook's "Award 2 Definitions" window doesn't correctly sort items, and leaves behind their "locked" state in the list entry after the sorting operation. This results in a bogus UI, maybe worse.
Tags:
Steps To Reproduce:

1) Fire up the logbook; load a populated database
2) Use the "Award Tracking" button in the database view toolbar to open an Award Tracking tab
3) Use the "Definitions" button on the Award Tracking tab to open the definition dialog
4) Select the "ARRL DXCC (HRD)" award
5) Press the "Copy" button to create a copy. Make a note of the new name. Also, make a note of the item's position in the list. Hopefully, it's last, buy maybe not.
6) Select that new item. Note that, since this copy is not a stock definition, it can be exported and the "Exported" button is enabled.
7) Select the original "ARRL DXCC (HRD)" award. This item is a stock definition, it's locked. When selected, the "Exported" button is disabled
8) Click the "Title" column header to sort by the name

9) Again, highlight the copied entry. It probably isn't where it was in the list previously, and exporting isn't possible.
10) Same experiment with "ARRL DXCC (HRD)". It's probably still sortable.
11) Select whichever item is now in the list at the ordinal position recorded in #5. That item is probably exportable, even though it's probably a stock item and shouldn't be exportable.

This experiment suggest that the attributes of the items aren't (fully) rearranged when the list is sorted. We can reinforce that evaluation:

12) Close the "Award 2 Definitions" dialog
13) Open it again, by clicking the "Definitions" button on the Award Tracking tab.

14) Find an item that's not "locked". Note its position in the list.
15) Sort by "Locked".
16) We can find items which are locked and exportable, and items which are unlocked and not exportable. They're probably at the position recorded in #14.
17) Sort again by "Locked", so we're going in the other direction.
18) Same problem: locked-ness isn't managed correctly.



Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3237 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-03-06 17:29 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.197  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: All
Sub-Module: (select)
Testing: Not Started
Summary: Build types should be fixed choices, not free strings
Description:
At present, the build type can be any string, arbitrarily. This isn't too useful.

It would be nice to enable or disable code based on build types -- certain code appears or disappears when a beta build is created, for example, for testing.

We should rearrange HRDVER.H and the build script so that the build type is given from a set of choices, which are fixed and drive on/off preprocessor macros to enable or disable code optionally.

We do need to still flag unsigned builds of any type. So I propose these mutually exclusive build types:

EXPERIMENTAL // not a beta or a release build; maybe a one-off for testing
BETA         // a public beta release
RELEASE      // a released and supported build


Additionally, the "UNSIGNED" flag may be set:

UNSIGNED == 0 // this build is signed
UNSIGNED == 1 // this build is not signed
SIGNED   == 1 // this build is signed
SIGNED   == 0 // this build is not signed



Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3203 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-02-28 09:53 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.907  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Logbook's "Countries" tab has mostly disabled context menu
Description: The "Countries" tab in the Logbook presents a context menu that's mostly disabled. Turns out these commands aren't relevant to the Countries tab, and the menu is left over from the regular Logbook database view. The commands should be removed, or maybe the Countries tab should get its own context menu with relevant commands. Presenting a menu with disabled commands implies that the user might do something (set a mode, make a selection, ...) that enables the commands.

Tags:
Steps To Reproduce: 1) Start up the logbook. Don't need any specific database.
2) Use the "Manager" command in the "Country" menu
3) In the resulting "Countries" tab, right-click to bring up the context menu.

BUG#1) Almost all of the choices in the context menu are disabled. The menu probably shouldn't be shown, since the commands here are for the Logbook database view, not the countries view. Or, maybe the context menu should be replaced with commands relevant to the "Countries" window.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3202 [2 - Next Dev List (Holding Area)] Bug minor always 2019-02-28 09:52 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.907  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Logbook country list window sorts numeric columns lexicographically
Description: The Logbook has a view which shows the "country list". Sorting a numeric column in this view looks like it does lexicographic comparisons rather than numeric comparisons.
Tags:
Steps To Reproduce: 1) Start up the logbook. Don't need any specific database.
2) Use the "Manager" command in the "Country" menu
3) In the resulting "Countries" tab, click on the "HRD Number" column to sort it ascending

BUG#1) The first few entries are "1", "10", "100", "10000", "101", indicating that the column is being sorted by comparing character values rather than numeric values.

Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3184 [2 - Next Dev List (Holding Area)] Maintenance minor always 2019-02-17 12:41 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.907  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: DM780
Sub-Module: IOTA
Testing: Not Started
Summary: Digital Master has code for a list of IOTA entities, but doesn't use it
Description:
The DM780 app has code to build a list IOTA entities.

This code is awkwardly shared with the Logbook's code that does the same thing. The XML file with the IOTA data is #included into the DM780 resource file from its location in the Logbook's source. The code to parse and manage the list of entities in memory, as well as perform searches and lookups, is copy-pasta between the Logbook and DM780.

Here's the punchline: as far as I can tell, DM780 doesn't even use the IOTA data.

We should double check that DM780 really doesn't use this data. If not, the DM780 implementation of the code and the cross-project dependency on the resource file should be removed. If the lookup is actually used, work should be done to consolidate the implementation and representation of the code.

Tags:
Steps To Reproduce:
In "Digital Master.cpp", see CDigitalMasterApp::LoadIOTA().

Additional Information:
Attached Files:
Notes
(0007460)
K7ZCZ   
2019-02-20 15:21   
Turns out the ITOA data is referenced from CWSJTFormView, which itself isn't used. So we have to figure out the disposition of thatcode, too, before removing this code.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3162 [2 - Next Dev List (Holding Area)] Bug minor always 2019-02-06 10:52 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.907  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Call lookup
Testing: Not Started
Summary: Logbook saves user passwords for call sign lookup services as plain text
Description:
The Logbook saves a user-entered password for third-party call sign lookup website as plain text on the user's machine. Any software or social engineering process that gains access to the settings file will have the user's password plainly available. While transparent encryption without another password to key the encryption doesn't completely hide the secret, it does help prevent otehr entities from directly viewing the credential and is a best security practice.

The product should be fixed to not store this credential in plain text. Instead, user-local encryption should be used.
Tags:
Steps To Reproduce:
0) if you already have a QRZ.com lookup password configured, go to step #6.

1) Start up the logbook
2) Use the "Tools" menu to find the "Config" tear-off
3) In the "Config" tear-off, use the "Callsign Lookup" command to get to the Callsign Lookup configuration
4) Enter a username and password for the QRZ.com lookup service. Doesn't ahve to be accurate.
5) Press OK to save and close the dialog.

6) Look for the ClientLogbookCallsignLookup.xml in the "%userprofile%\AppData\Roaming\HRDLLC\HRD Logbook" directory.

BUG#1) This file contains the entered QRZ.com password as plain text

This can be repeated with the passwords for the QRZ CQ, Ham Call, an Ham QTH lookup sources.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3158 [2 - Next Dev List (Holding Area)] Bug crash always 2019-02-04 16:05 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.187  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Changing radio control slider name causes crash in Rig Control when Logbook has old name in Radio pane layout
Description: We've changed slider names in Rig Control with impunity. Turns out, that practice destabilizes the product because some code doesn't check to see if slider names are invalid before performing lookups of the names.


Tags:
Steps To Reproduce: 1) Start up Rig Control.
2) Start Logbook, get them connected.
3) Edit the Radio Pane in Logbook to include the "AF Gain" control for the connectd radio.
4) Save the layout.
5) Close Logbook and Rig Control.
6) Edit the Rig Control application to use a different name for "AF Gain", like "AF Gain NEW NAME HERE".
7) Rebuild the Rig Control application.
8) Start Rig Control again
9) Start Logbook, get them connected again.


BUG#1) When Logbook starts, Rig Control will crash.


The culprit is an un-checked call to CRadioOptions::GetAdvancedIndex(). Several such calls exist in CRadioView::HandleGet(), which is the function that tries to handle commands sent from external clients to Rig Control. The lookup for "AF Gain" fails. The index returned from GAI() is invalid, then, but still used in subsequent calls. Those calls walk unowned memory and the application crashes.

Additional Information:
Attached Files:
Notes
(0007257)
K7ZCZ   
2019-02-04 18:18   
I've added some defensive code with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4806

With that change in place, the apps won't get sick anymore. However, the broken slider control remains. The user won't be able to move it, it just sits there. They'll probably eventually figure out that they can delete it and replace it with the right control with a new name. But I think we can do a bit better. At startup (or at connection time) the Logbook can search the available controls to make sure they all match and issue a warning that they'll be removed... then remove them. This won't happen often (hopefully), so I don't think we're obliged to make anything terribly elegant or complete. I feel that it's adequate to just explain what's going on, and fix up the issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3156 [2 - Next Dev List (Holding Area)] Bug minor always 2019-02-04 12:40 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.907  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: ALE Window
Testing: Not Started
Summary: Logbook ALE band tracking doesn't give clear indication of invalid bands
Description:
The "band" control in the ALE often displays an incorrect band designation, or none at all. This behaviour is either completely incorrect, or confusing to customers, who erroneously assume that the ALE has "stopped tracking" the radio's setting.
Tags:
Steps To Reproduce:

1) Start up Rig Control. Connect to a demo-matic radio; I used the FT-450 Demo.
2) Start up Logbook. Make sure Logbook gets connected to Rig Control and sees the radio.
3) In Logbook, open any database you'd like.
4) Use the "Add" button in the Logbook toolbar to add a new entry.
5) In the resulting "Add Logbook Entry" dialog, make sure the "track" buttons next to "Band" and "Mode" are marked.
6) Using Rig Control, tune the radio to 14.150
7) Return to Logbook. Note that the ALE correctly indicates "20m" in the "Band" drop down.
8) Tune the radio to 14.850 in Rig Control
9) Note that the Logbook's ALE window has nothing selected in the "Band" dropdown, now.

BUG#1) This behaviour is by design because 14.850 MHz isn't in the 20-meter amateur band. The ALE only accepts ADIF-valid input, so it can't report a QSO on 14.850 as being in any recognized amateur band. We receive complaints about "not tracking", however, so it must be that this behaviour isn't understood or is surprising to customers. Should the ALE display something more prominent when the frequency can't be matched to a band?


10) Tune the radio to 18.100 Mhz in Rig Control
11) The ALE window correctly shows "17m" in the Band dropdown.

12) Tune the radio to 18.190 MHz in Rig Control

BUG#2) The ALE shows the band to be 15m. This is wrong. Not only is 18.190 outside of the 17m amateur band (from 18.068 to 18.168 MHz), it's certainly not in the 15-meter band. There are many locations in the product that, when they can't find a band, compute the band by calculating a band name (in meters) by dividing 280 by the frequency in megahertz and truncating the result. 280 / 18.190 is 15.393; truncating that gives 15m.


To solve Bug#1, we'll need to agree on a way to show the user that they've tuned outside of the band. Maybe we agree that emptying the band drop-down is enough, but that doesn't seem to be true.


To solve Bug#2, we'll need a solution for Bug#1, since 18.190 is outside of the band. We'll also have to agree that code in the product which tries to compute the band by doing math isn't the right for the product.


Additional Information: The code in question is in CLogbookRecordDefns::FreqToBand(), and also in CDXClusterDlg::FreqToBand().

The ARRL band plan is here: http://www.arrl.org/band-plan

Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3146 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-02-01 11:37 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.188  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Two ways to set time zone in Satellite Tracker; only one redraws
Description: The Satellite Tracker app allows the user to choose between displays in UTC and Local Time. Two different UIs provide access to this setting, but they work differently. Specifically, one caues the displayed information to redraw with the new setting, and the other doesn't. Failing to update the screen with the new settings is confusing to users and should be repaired.
Tags:
Steps To Reproduce: 1) Start the Satellite Tracker app
2) In the Satellite list toolbar, press the "Enable All" button
3) In the main window's toolbar, press "Next Passes" to bring up a passes view
4) Make sure the passes view has the "Elevation" button selected to show elevation graphs
5) Use the "Options" button in the passes view toolbar to reach the "Next Passes Optoins" dialog
6) Activate the "Formats" tab in the "Next Passes Options" dialog
7) Change the setting for time zone; doesn't matter where it lands, as long as it changes.
8) Press OK to close the Options dialog
9) Note that the graphs redraw with the new time zone setting.
10) In the "Tools" menu, use the "Options" command
11) In the resulting "Options" dialog, activate the "Formats" tab
12) In the Formats tab, switch the setting for the time zone; doesn't matter where it lands, just switch it
13) Press OK to dismiss the "Options" dialog

BUG#1) The graphs don't redraw; the setting isn't immediately honored

14) SElect the "Satellite Definitions" tab
15) Use the "Next Passes" button in the main window's toolbar to create another passes view

BUG#2) The graphs in the new view still don't have the new time zone setting

16) Close the app
17) Restart the app
18) Open a new passes view with the "Next Passes" button.
19) It is onyl after a restart thta the new setting is used.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3139 [2 - Next Dev List (Holding Area)] Maintenance minor always 2019-01-30 13:06 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.188  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: General
Testing: Not Started
Summary: CNextPassesView and CPaneNextPasses in Satellite Tracker are copy-and-paste
Description: In the Satellite Tracker app, the docking "Next Passes" pane and the "Passes" view have very similar functionality. Problem is, they're implemented by code that's been copied and pasted from one to the other.

This results in several problems; most notably the need to fix bugs in both implementations, plus confusion about which window is which when tracking down issues.

Ideally, a class is made of the passes tracking code and shared between the two UI implementations.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0007162)
K7ZCZ   
2019-01-30 13:08   
This checkin just adds some comments about the copy-and-paste implementation.
Hopefully, it aves others from manually figuring this out. (Or, saves me from again realizing what's wrong next time I dive in.)
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4783

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3042 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-01-06 15:30 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.166  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Rig Control
Testing: Not Started
Summary: Rig Control's Command Tester feature falsely reports comamnd errors
Description:
The Command Tester feature incorrectly reports errors from some commands.

Tags:
Steps To Reproduce: 1) Fire up Rig Control
2) Don't connect to a radio; instead, skip the "Connect" dailoguse
3) Use the "Command Tester" command in the "Tools" menu.
4) Use the "Yaesu (New)" command set to connect to your Yaesu radio; I'm using an FT-991.
5) Set the raio to a CW mode; either CW USB or LSB is fine.
6) Use the "F/M-List" button to get to the soft menu
7) In the soft menu, find the page with the "APF" control on it.
8) Turn on the "APF" filter from the radio's soft menu.
9) Use the CAT Command Tester to issue the "FA;" command. It works fine; the frequency is reported and marked [OK].
10) Issue the "CO030021;" command to change the APF filter center frequency to -40 Hertz.

BUG#1) The command works; the radio shows "APF -40 Hz" as expected. But the Command tester reprots "[Error]".

11) Try again; issue the "CO030010;" command to change the APF filter to -150 hertz.

BUG#2) The command worked again because the radio shows "APF -150Hz" as expected. But the command tester again reports "[Error]".

Note that this has nothing to do with the APF feature of the radio (or the frequency reporting feature, LOL). I arbitrarily chose those commands because they were close at hand, and demonstrate that sometimes the status is correctly reported, and sometimes it is not.

Additional Information:
Attached Files: FalseError.png (23,439 bytes) 2019-01-06 15:32
https://development.hamradiodeluxe.com/file_download.php?file_id=632&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2989 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2018-12-13 15:38 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Rig Control: consider toggle buttons that show state with label text
Description: We have on/off buttons in the Rig Control app now which turn color when active. "ATT" might have white letters when disabled and yellow letters when enabled, for example.

Some buttons would be better to change their title to show their state. A toggle between FM modes might show "Wide" or "Narrow" instead of an on/off state, even though the button is really turning "Narrow" mode off and on.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2856 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-08-24 12:25 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.876  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: Satellite Tracking: crash while viewing passes in text
Description: This crash is from the Dev Dashboard, so the repro is pretty weak. From the stack, though, we can see that the user has clicked the "Text" button in the toolbar on the "Passes" view. That should get some text information about the dispalyed passes, write them to a file, and then ask the shell to open the default editor for that file.

While the shell is waiting for the file to open, it pumps some messages. The pump catches a WM_TIMER message and dispatches it. The timer message causes a refresh of the Passes pane, and ends up crashing when it trips over a bad string pointer.

A spreadsheet with the details of the stack are attached.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mantis2856Stack.xlsx (12,118 bytes) 2018-08-24 12:26
https://development.hamradiodeluxe.com/file_download.php?file_id=522&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2752 [2 - Next Dev List (Holding Area)] Bug crash have not tried 2018-05-29 20:38 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.4.0.842  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Logbook
Sub-Module: Data
Testing: Not Started
Summary: Logbook: crash reported when adding second MySQL database to configuration
Description: A customer has reported that adding a second MySQL database to the Logbook configuration causes a crash.

This issue was discovered during testing of changes to the logbook to defend against bogus database configuration. There's little reason to believe this crash is related to or caused by the enhanced error handling; see Issue 2720 for more details there.

The call stack from the crash is attached below. We can see that a configured data source is being used to access the database in a background thread. There are several concurrency management issues in the Logbook, and I believe this is just another instance of that problem.
Tags:
Steps To Reproduce:
Additional Information:
0:023> .ecxr
eax=00000000 ebx=20f7cf88 ecx=02000000 edx=fffffffd esi=061594e0 edi=09d7f9f8
eip=586803b7 esp=20f7ceac ebp=20f7ced8 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
odbc32!EnterStmtCS+0x4b:
586803b7 ff481c          dec     dword ptr [eax+1Ch]  ds:002b:0000001c=????????
0:023> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 20f7ceb0 58685d37 00000000 20f7cf58 20f7cf88 odbc32!EnterStmtCS+0x4b
01 20f7ced8 0106e669 09d7f9f8 20f7cf88 00000000 odbc32!SQLNumResultCols+0x97
02 20f7cf00 01070f73 a48db71f 00000001 194d0a30 HRDLogbook!CRecordset::AllocAndCacheFieldInfo+0x17 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dbcore.cpp @ 2651] 
03 20f7cf34 0151e6d3 00000002 00000000 00002006 HRDLogbook!CRecordset::Open+0xdd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dbcore.cpp @ 1181] 
04 20f7fab8 0156f1f4 20f7fae0 194d0a30 0156f120 HRDLogbook!CBackgroundProcessingThread::CountryLookup+0x4b53 [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 3967] 
05 20f7fb00 760c8484 194d0a30 760c8460 d30cc234 HRDLogbook!CDXCObject::LookupThreadProc+0xd4 [c:\ham radio\logbook\hrdlogbook\dxclusterobject.cpp @ 1352] 
06 20f7fb14 778d2ec0 194d0a30 d2820967 00000000 kernel32!BaseThreadInitThunk+0x24
07 20f7fb5c 778d2e90 ffffffff 778ededb 00000000 ntdll!__RtlUserThreadStart+0x2f
08 20f7fb6c 00000000 0156f120 194d0a30 00000000 ntdll!_RtlUserThreadStart+0x1b

Attached Files:
Notes
(0005148)
K7ZCZ   
2018-05-29 21:05   
From the dump, I also quickly notice that the user has a pretty old version of the MyODBC driver. 3.51 is a long time ago; current versions are 5.x.something. The user should be encouraged to upgrade, though I figure the problem is really caused by our bad concurrency management.

0:023> lmDvmmyodbc3
Browse full module list
start    end        module name
11150000 112cf000   myodbc3    (deferred)             
    Image path: C:\Windows\System32\myodbc3.dll
    Image name: myodbc3.dll
    Browse all global symbols  functions  data
    Timestamp:        Sat Oct 15 14:25:21 2005 (435173C1)
    CheckSum:         00000000
    ImageSize:        0017F000
    File version:     3.51.12.0
    Product version:  3.51.12.0
    File flags:       0 (Mask 3)
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
(0005150)
g3ypp   
2018-05-30 03:18   
The crash did not occur when adding a new configuration to the logbook - rather the logbook crashed on opening an additional already configured log. This has not occurred in previous releases. I have a total of 4 MySQL logs configured and can usually open and close them without issue. This crashing on opening started with .839 Beta.
(0005151)
K7ZCZ   
2018-05-30 08:00   
I see, sorry for the confusion. All I had was the sentence you provided in the other issue.

Can you please provide a clear description of the problem with repro steps? While the minidump makes the location of the crash clear, it doesn't provide information about the preconditions and actions you took to realize the symptom.
(0005152)
g3ypp   
2018-05-30 08:23   
With HRD Logbook open and one log database open from startup
Go to Manager
Select another logbook in the list to open by clicking/highlighting it
Click on Open

Log book appears to open

Click OK on Manager

Logbook crashes with minidump
(0005154)
K7ZCZ   
2018-05-30 09:04   
Thanks for the description; with that information, I'm enabled to dig into the issue.

I've related this to 2098, which tracks the Logbook concurrency problems in general

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2733 [2 - Next Dev List (Holding Area)] Enhancement minor always 2018-05-21 08:19 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Setup
Sub-Module: Appearance/UI
Testing: Not Started
Summary: Setup: opportunity for branding
Description: The setup UI uses the default InstallAware background art on all of its pages. Some pages have a header, some have a margin, as shown in the attached images.

To make the setup look more finished and reinforce our own branding, we should provide our own artwork in these areas.

Tags:
Steps To Reproduce: 1) Fire up setup
2) Observe UI border on welcome step
3) Press Next; observe UI in margin on EULA step



Additional Information:
Attached Files: SetupMargin.png (18,722 bytes) 2018-05-21 08:19
https://development.hamradiodeluxe.com/file_download.php?file_id=400&type=bug
png

SetupHeader.png (27,302 bytes) 2018-05-21 08:19
https://development.hamradiodeluxe.com/file_download.php?file_id=401&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3408 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-07-29 11:05 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: develop mechanisms, guidance to show license-disabled features
Description:
Given the expiry of a user's license, some features may not be available in their install. We should enumerate mechanisms for showing users that features are missing, and develop a guide for showing the user which features are missing and guiding them toward a renewal or upgrade.

Our first license-protected feature is the panadatper display. A user with an old license won't be able to access it.

The panadapter display will be accessed by a menu choice in rig control; also maybe with a tool bar button, if we can get artwork for the button icon. If the user has a current license (and a supported radio) then these UI elements are enabled and usable. They lead to the panadapter UI.

If the user doesn't have a current license, what do they see? Could be any one of these choices:


  1. the menu choices (and tool bar button) are removed

  2. the menu choices (and tool bar button) are disabled, even with a connection to a supported radio

  3. the menu choices (and tool bar button) are active in the presence of a good connection, but lead to UI that explains the feature is missing

  4. the menu choices (and tool bar button) are active with a good connection, but lead to a time-limited demo of the feature



Maybe there are other alternatives. And there certainly need to be other mechanisms for features which have a different access mechanic -- not all features are accessed through a menu item or tool bar button, so they'll need their own solution patterns.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3388 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-07-10 13:36 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: "Meter" slider doesn't work for TS-990
Description:
The Rig Control application has a "Meter" slider that lets the usr select the displayed metered quantity -- SWR, Power output, final current, and so on.

The TS-990's MT command behaves differently than all other Kenwood radios. It looks like some accomodation was attempted in encoding the string for the Meter slider in Rig Control, but no effort was mde in actually fixing the code to use that different string.

I don't have access to a TS-990, so I can't verify or fix this issue, but by reviewing the code it certainly looks like there's a problem.

Tags: Kenwood, TS-990
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3387 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-07-10 10:52 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: No support for attenuator on TS-990 radio
Description:
The Kenwood TS-990 radio has an attenuator, but Rig Control doesn't support it in any way; no control for the attenuator is offered in the Rig Control UI.

Thing is, the Attenuator command (RA) for the TS-990 doesn't fit well with the Rig Control UI model. The set command only sets the currently selected receiver -- A or B. Rig control doesn't know which receiver is selected, so it can't reflect the setting in the UI directly. As such, a straight-forward solution isn't possible. If we implemented an ATT dropdown in the same way we do for most other radios, it wouldn't work right and would change the A or B setting unintuitively, and always report either A or B's setting.

Perhaps we can re-work Rig Control so that it's more readily aware of the radio's state, and we could then have a better chance of implementing controls for more advanced radios like the TS-990.

Tags: Kenwood, TS-990
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3386 [2 - Next Dev List (Holding Area)] Bug minor always 2019-07-10 10:32 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Appearance/UI
Testing: Not Started
Summary: "Tools" menu in Rig Control app could use design attention
Description:
The "Tools" menu in the Rig Control app is a bit of a mess.

Some commands (like "Calendar") might be removed -- see Mantis 2232.

A few commands misspell "Icom" as all caps and should be fixed.

Some commands have mnemonics, some don't. Commands could be better grouped.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0008211)
K7ZCZ   
2019-07-10 10:48   
this checkin to 6.7 adds a couple of useful keyboard mnemonics:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5060

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3383 [2 - Next Dev List (Holding Area)] Enhancement minor have not tried 2019-07-09 18:59 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: Add support for RIT/Delta-Freq for TS-890
Description:
The Kenwood TS-890 supports RIT/XIT frequency offets to help accurately tune or "micro-split" CW work. The feature of the radio is arranged in such a way that supporting it from Rig Control will be difficult.

Intuitively, we'd want a single slider control that sets the frequency offsets; the radio can handle +-9999 hertz. An on/off button could handle turning the RIT/XIT setting on or off.

The radio's command interface provides the RF command to read the frequencies. A separate RC command is given to reset the offset frequencies to 0, which effectively turns off the feature. The frequency is set with RU or RD, which takes a frequency value.

At this time, Rig Control sliders can't use such a combination of comamnds to control the offset frequency. Further, the on/off button implementation can't handle using a comination of commands to test, set, or clear the on/off state.

RIT/XIT is a popular feature for advanced CW hams, and we should find a way to get some controls implemented that can suppotr the radio's mechanism for these settings.
Tags: Kenwood, TS-890S
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3382 [2 - Next Dev List (Holding Area)] Bug minor have not tried 2019-07-08 14:55 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.236  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Rig Control
Sub-Module: Radio Support
Testing: Not Started
Summary: "Extended Menus" feature doesn't work for TS-990
Description:

Some radios expose groups of settings in "extended" menus, outside of the normal control command structure. The "Extended Menus" feature in Rig Control allows users to manipulate these settings. Rig Control has support for the extended menus in the Yaesu FT-2000 and the Kenwood TS-2000, TS-4890, and TS-990.

Support for the TS-990 doesn't work. While I don't have one of these radios to test with specifically, the radio's documentation says that the radio accepts a very different extended menu command (EX) format than the code uses. Further, the settings given in the menu don't (at all!) match the settings given in the radio's manual.

The code should be corrected to work with the TS-990. It should also be reviewed and tested, as I think we have reason to believe it was never given any such attention previously. (Seems like the definitions for the TS-2000 were copied to the TS-990 and assumed they'd work ... but the radios are very (!) different and the menu struc ture isn't nearly the same.)
Tags: Kenwood, TS-990
Steps To Reproduce:
1) Start up Rig Control. Connect to TS-990
2) Use the "Kenwood" command in the "Extended Menus" tear-off in the "Tools" menu
3) Use the "Refresh" button to re-load the radio's settings

BUG#1) Doesn't work; none of the settings are reflected properly in the Rig Control UI


Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3368 [2 - Next Dev List (Holding Area)] Bug minor always 2019-06-18 18:43 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6.0.214  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: SW License Mgmt
Sub-Module: SW License Client
Testing: Not Started
Summary: possibly spurious data written to registry?
Description:
The product writes spurious data to the registry. Maybe it has meaning, maybe it doesn't. I'm opening this issue because I can't quite figure out what writes it; if it's a bug and we're unintentionally writing uninitialized or unintentional data, we should fix it and clean it up so that it isn't a security or stability issue. If it's intentional, it seems like we should give the data a good format and proper name.


Tags:
Steps To Reproduce:
1) Setup the product, use a valid license keys
2) Examine this key in the registry: "Computer\HKEY_CURRENT_USER\Software\Amateur Radio\HRD User Profile\Keys"
3) For me, I have value with the name ":6.0:2004-0-781" and no value.

Maybe the first two digits are a vesion number (but why not "6.5" instead of "6.0"?). Maybe the second field is meant to be a date, but it's also incorrectly formatted. Or, maybe my guesses are wrong.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3364 [2 - Next Dev List (Holding Area)] Maintenance minor have not tried 2019-06-16 23:15 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.208  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: (select)
Testing: Not Started
Summary: consider upgrading and/or licensing satellite tracking library
Description:
The Satellite Tracker application uses a pretty old version of a third-party library which comes from http://www.zeptomoby.com/satellites/

I don't know if we have a license for this library, so I don't know which edition (Public, Standard, or Professional) we have. It looks to me like our snapshot of that code came from 2003 or so. The Public edition was last updated in June of 2017, according to the website.

We should be usre that we're in compliance with the terms of the library's license whatever we do. We might consider upgrading to a more capable version of the library, if it adds features that improve the product. (See Mantis 3363 -- we should research it a bit, but I think the Professional version supports the closed-form computation we'd like to see.)

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3363 [2 - Next Dev List (Holding Area)] Enhancement minor always 2019-06-16 23:12 2020-07-02 02:11
Reporter: K7ZCZ Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5.0.208  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Module: Satellite Tracking
Sub-Module: Functional
Testing: Not Started
Summary: Satellite tracker does iterative math
Description:
The satellite tracker does iterative math, which is very slow.

To figure out when a satellite rises (appears above the horizon), the application uses the satellite's Kepeler data and the station's location and does some math. The math is pretty involved -- it can take a few hundred milliseconds to complete. The operatoin gives the position of the satellite by computing its azimuth. If the azimuth is below the horizon, the code advances the time reference used in the computation and tries again.

The iterations continue until the azimuth is positive -- above the horizon. The approach has seveal problems.

One is that the satellite may never become visible. The code has to eventually give up, and that takes time. The logic for giving up might not be right.

Another is that the accuracy suffers. The times resported for rising and setting satellites is only accurate to the change in each iteration. If an iterative test at 01:00 says the satellite isn't visible and the test at 01:05 is visible, the satellite is reported as rising at 01:05. But the satellite might have actually risen at 01:01.

Finally, it's just slow. It would be faster and could be more accurate to adaptively iterate (change the step of each iteration). If a closed-form solution for the math could be found, even if it was more computationally expensive, it would execute only once and return an answer. That would also hopefully result in an immediate detectable faliure for satellites that won't rise over the horizon at the observing station.
Tags:
Steps To Reproduce:
Additional Information: Some more notes are in the related issue. I've opened this issue to continue tracking this opportuity because the related issue was closed.

Attached Files:
There are no notes attached to this issue.

View Issue Details
</