View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003436 | 1 - Backlog | Bug | public | 2019-08-22 09:48 | 2019-08-24 13:17 |
| Reporter | KC7FPF | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0003436: Save VFO B (sub-Frequency) in the database) | ||||
| Description | The "Save VFO B (sub-frequency) in the Database" is checked in the Options drop-down in the ALE window. You create a new QSO and save it. The VFO B freq. is added to the database. The "Save VFO B (sub-frequency) in the Database" is Un-checked in the Options drop-down in the ALE window. The QSO record is opened and updated without making any changes. HRD deletes the VFO B freq. IMHO a good program never deletes data unless it specifically directed to do so. My recommendation is: Whenever the "Split" option is active in the radio, save the VFO B freq. to the database. If the split option is not selected, do not save the VFO B freq. And, add the VFO B freq. field to the ALE someplace so it can be edited by the user. As it is now, either the Logbook bulk editor or a third party dB program must be used to fix the Freq(Rx). Why is this a big issue, you ask? LOTW has to match bands to confirm a QSO. If HRD uploads a VFO B freq that is a different band than the VFO A band, you can't get credit for the QSO. I just spent the better part of a day manually fixing my logbook and LOTW | ||||
| Steps To Reproduce | this is item has been in the HRD logbook as long as I can remember. You have to go into the ALE window/Options. Once there you have to manually uncheck "Save VFO B (sub-Frequency) in the database) If this is checked when you upload to LOTW it will come back with an error. | ||||
| Tags | No tags attached. | ||||
| Module | Logbook | ||||
| Sub-Module | ALE Window | ||||
| Testing | N/A | ||||
